Eric,
Many thanks for the examples and thoughts. The semantics we want is
something like your example 5. For example, in the original Open
Archives metadata set (see
http://www.openarchives.org/sfc/sfc_oams.htm#oamsseman), which will be
reconsidered at our upcoming OAi technical meeting, we create instance
data like:
<oa:author>
<oa:name>Carl Lagoze</oa:name>
<oa:organization>Cornell University</oa:organization>
</oa:author>
In your example, you enclose this all in 'dc:creator' tags. However,
this, of course, means not using an appropriate literal in Tom Baker's
terms and ends up getting us into all sorts of dumb down issues.
So, what one would want to do is something like:
<oa:author>
<dc:creator>Carl Lagoze</dc:creator>
<oa:organization>Cornell University</oa:organization>
</oa:author>
Jane, I believe this is something that can be defined in an xml-schema,
right?
Eric, how about in an RDF-schema.
Even if so, we'd have to think about how clients might be able to use
such namespece elements buried at arbitrary depths in an xml tree.
perhaps Dan Brickley, who has tracked closely the xml query language
stuff might have something to say.
After all this is considered I think we have to consider the tradeoffs
of projecting a "pure" dc-based record (one containing only DC namespace
elements) versus this mix and match capability as a means of promoting
discovery interoperability.
Finally, I'll add one more factor to the discussion. Elements like
dc:coverage, which is inherently messy, have semantics which in many
other vocabularies that are split among several elements. Certainly a
pure application profile without duplicated information all over the
place would be very messy.
Carl
> -----Original Message-----
> From: Miller,Eric [mailto:[log in to unmask]]
> Sent: Monday, August 21, 2000 1:32 PM
> To: 'Carl Lagoze'; 'Jane Hunter'
> Cc: [log in to unmask]; [log in to unmask]
> Subject: RE: Applications profiles
>
>
> Carl writes...
>
> > This, as a matter of fact, is exactly the type of situation as we
> > re-consider our "core metadata set" for the
> > (http://www.openarchives.org). We need an element that
> > expresses simple
> > "title" semantics, and we might as well use the title
> element from the
> > DC namespace for this. We also need another element with meaning
> > "miscellaneous comments about this entry" which doesn't fit
> > cleanly into
> > the DCES namespace, so we plan to mix that in our
> application profile.
> >
> > In this context, however, the problem I raised earlier
> > exists. We want
> > more expressive "creator semantics" including affiliation
> > which doesn't
> > match the semantics of the DC "creator" element. So, do we
> have a DC
> > creator element that co-exists with a more expressive OAI creator
> > element?
>
> I think we discussing here only a small finite set of
> possibilities. Which
> of these possibilities one would use depends on the
> particular goals of any
> project. I've tried to capture this set as a exercise to a)
> see if it is
> indeed finite and b) to demonstrate how this might be accomplished in
> XML/RDF.
>
> Ok... here goes:
>
> 1) Use established semantics
>
> In a RDF schema located at http://purl.org/dc/elements/1.1/
>
> <rdf:Property rdf:about="http://purl.org/dc/elements/1.1/creator">
> <rdfs:label>Creator</rdfs:label>
> <rdfs:comment>An entity primarily responsible for making the
> content of the
> resource.</rdfs:comment>
> </rdf:Property>
>
> And in the metadata instance data:
>
> <dc:creator>Carl Lagoze</dc:creator>
>
>
> 2) Use new independent semantics
>
> In a RDF schema located at http://www.openarchives.org
>
> <rdf:Property rdf:about="http://www.openarchives.org/vocab/author">
> <rdfs:label>Author</rdfs:label>
> <rdfs:comment>An openarchives author.</rdfs:comment>
> </rdf:Property>
>
> And in the metadata instance data:
>
> <oa:author>Carl Lagoze</oa:author>
>
>
> 3) Use new semantics (but relate to existing semantics)
>
> In a RDF schema located at http://www.openarchives.org
>
> <rdf:Property rdf:about="http://www.openarchives.org/vocab/author">
> <rdfs:label>Author</rdfs:label>
> <rdfs:comment>An openarchives author.</rdfs:comment>
> <!-- define refinement relationship between oa:author and
> dc:creator -->
> <rdfs:subPropertyOf
> rdf:resource="http://purl.org/dc/elements/1.1/creator"
> />
> </rdf:Property>
>
> And in the metadata instance data:
>
> <oa:author>Carl Lagoze</oa:author>
>
>
> 4) Place additional contraints on existing semantics
>
> In a RDF schema located at http://www.openarchives.org
>
> <rdf:Property rdf:about="http://purl.org/dc/elements/1.1/creator">
> <!-- define constraint on dc:creator ... value is a Person -->
> <rdfs:range
> rdf:resource="http://www.openarchives.org/vocab/Person" />
> </rdf:Property>
>
> <rdfs:Class rdf:about="http://www.openarchives.org/vocab/Person">
> <rdfs:label>Person</rdfs:label>
> <rdfs:comment>A Person</rdfs:comment>
> <rdfs:Class>
>
> <rdfs:Property rdf:about="http://www.openarchives.org/vocab/name">
> <rdfs:label>Authors Name</rdfs:label>
> <rdfs:domain
> rdf:resource="http://www.openarchives.org/vocab/Person">
> </rdfs:Property>
>
> <!-- declare other properties for email and affiliation in a
> similar fashion
> -->
>
> And in the metadata instance data:
>
> <dc:creator>
> <oa:Person>
> <oa:name>Carl Lagoze</oa:name>
> <oa:email>[log in to unmask]</oa:email>
> <oa:affiliation>Cornell</oa:affiliation>
> </oa:Person>
> </dc:creator>
>
> 6) Place additional contraints on new semantics
>
> (similar to #5)
>
>
> Having done this, I'm in agreement with Jane that this in essence just
> indeed more data. I think however a real benefit of these application
> profiles is with the actual description and management of
> these schemas.
> Agreeing on both a common way of effectively reusing existing and/or
> defining new semantics and then *describing* these profiles
> in such that
> they can be effectively located and utilized is a huge benefit to all
> metadata communities.
>
> Or to echo Pricilla's point "It doesn't seem much of a big
> deal to me to
> call it an application profile. I'm actually very interested
> in being able
> to see the application profiles adopted by other implementations."
>
> --eric
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|