On Fri, 23 Jan 1998, John A. Kunze wrote:
> > Date: Fri, 19 Dec 1997 11:53:12 -0500
> > From: David Bearman <[log in to unmask]>
> > ...
> > I. It is important to indicate the relation between one information
> > resource and another in metadata for discovery. Because each information
> > resource may have its own metadata set, these relations need to be explicit.
>
> David,
>
> I think your report on the Relation semantics is very clear. One missing
> piece is that the resources on either side need to be explicit. Currently
> we only make the second resource explicit (by using its identifier), while
> the first or "present" resource (the resource being described) is implicit.
> This seems to me missing in our discussion and in the basic DC RFC (#1).
>
> There's no problem in situations where the implicit first resource is
> obvious, as in the embedded metadata case. But it's definitely a problem
> in the non-embedded case because we haven't left a place in either Relation
> or Source for the first resource to be indicated.
>
It may be that I don't understand what you're talking about. But it
seems to meyou are saying that there are no explicit way of expressing
"starting" and "convergence" conditions for the metadata recursion
implied by the relation group's proposal (this was pointed out
recently by Simon Cox on this list). Given the limitation that
everything is optional, I think we can not go any further than saying
that it is an implementation issue and the boundary conditions (so to
speak) if the recursion will be obvious from the context.
Assume that we have a number of objects labelled 1, 2, ..., i, ... n,
each of which being a part of its successor in the sequence. The
architecture of the relations will be clear from the context:
DC.Identifier 1
DC.Relation.IsPartOf 2
DC.Identifier 2
DC.Relation.HasPart 1
DC.Relation.IsPartOf 3
...
DC.Identifier i
DC.Relation.HasPart i-1
DC.Relation.IsPartOf i+1
...
DC.Identifier n
DC.Relation.HasPart n-1
The first object has no "HasPart" and the last no "IsPartOf"!
> One solution would be to let Relation (and Source) contain an optional
> extra identifier for the first resource. This would probably help
> implementation of even the embedded case, since that metadata will
> likely be separated from the mother resource when it goes into the
> search system indexes, and there both the first and second resources
> must be explicit.
Is this really necessary? Or am I not awake this Monday morning?
>
> -John
>
I'm worrying a bit about other relations than those implied by the
report by David and friends. Howver, they could possibly fall into
their broad taxonomy (as being "Part/Whole relations are those in
which one resource is a physical or logical part of another"):
DC.Relation.IsMemberOf
DC.Relation.HasMember
The first is has the connotations needed for describing relations
between different collections of DC record-like objects (like a
collection of resources about flutes which is a member of a larger
collection of collections covering woodwind instruments which together
with collections on brasswind instruments forms a collection of
... and so forth).
Child-parent relations
DC.Relation.ChildOf
DC.Relation.ParentOf
could possibly be needed in the description of more generic tree like
structures (so could sibling relations).
Anyway, all this might be of academic interest only ;-)
Cheers,
Sigfrid
|