Carl writes....

> 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.

Ahh... so this helps define some of the "goals" associated with any
particular project I was referring to. Tom's point about an appropriate
literal can be accomplished in a variety of ways depending on the particular
syntactic representation. Further below for example I'll suggest how this
might be accomplished in RDF. 

> 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>

hmm... I think your confusing the issues with arbitrary syntactic nesting.
What are you really trying to say here?  In OA, an author only be a Person?
That oa:author is a refinement of dc:creator?  That we want to associated an
"organization" with what... the Person who is the author?

Also, if part of your goals are to include a "dumb down" value for
dc:creator you have the option of (a) leaving it to the application to
define what the default string should be or (b) specifying a default "dumb"
string.  Dublin Core Applications have been striving for (b) but most often
getting (a).

If (a) then basically this is application dependant, if (b) then this become
syntax dependant.  If we choose, RDF for example, we have a default value
property (rdf:value) that can be utilized. Taking example 5, therefore we
would say: 

<dc:creator>
  <oa:Person>
    <rdf:value>Carl Lagoze, [log in to unmask]</rdf:value>
    <oa:name>Carl Lagoze</oa:name>
    <oa:email>[log in to unmask]</oa:email>
    <oa:affiliation>Cornell</oa:affiliation>
  </oa:Person>
</dc:creator>

> 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.

Right... You've identified a big problem with arbitrary XML content.  With
the above RDF mechansims, we have far less of a problem.

> perhaps Dan Brickley, who has tracked closely the xml query language
> stuff might have something to say.

Hmmm... I might be jumping ahead here (Dan correct me if I'm wrong) but
after talking with the XQL and Quilt people, it seems to me the answer is
"sure this can be done if we know a priori the syntactic structure".  The
syntactic structure that the open archives group might choose might not be
the same as other ommunities.  Therefore integrating data from an open
archives project with other inititatives that choose a different structure
is far more difficult.

> 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.

absolutely... again part of the goals for any given project.  How
interoperable do we wish to be?  Its all well and good to say it, but when
we have to choose syntactic structures that follow a given pattern, that's
where we really test the goals.

> 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.

Coverage is a particular favorite of mine :) Can you give me an example of
what you mean by this?  If so, I'll try and define such an application.  It
seemed that the previous examples was an effective example of mixed
vocabularies.  I've tried this with dc:coverage as well, but might have
missed something.

--eric

 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%