 |
 |
Dear John, I'm not sure I understand your point. we've just implemented this with in a test dataset for the Art Museum Image Consortium Library and it seems to me that bi-directional pointing is explicit with the structure we already have: Resource #1 has metadata set #1 in which: Dc.Identifier=Identifier of Resource #1 DC.Relation.Type=HasFormat DC.Relation.Identifier=Identifier of Resource #2 Resource #2 has metadata set #2 in which: DC.Identifier=Identifier of Resource #2 DC.Relation.Type=IsFormatOf DC.Relation.Identifier=Identifier of Resource #1 it might also have another occurence of DC.Relation.type and DC.Relation.Identifier with other values, which raises the questions of the syntax of these things in RDF and how we keep repeating groups in sync, but that's a different issue (I think) or is it what you are getting at? are we missing something? Do you want to see the full examples? David At 07:10 AM 1/23/98 -0800, 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. > >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. > >-John > > > David Bearman, President Archives & Museum Informatics 5501 Walnut St., Suite 203 Pittsburgh, PA 15232 USA ph. + 1-412-683-9775 fax + 1-412-683-7366 email: [log in to unmask] URL: www.archimuse.com