Hi Jeffery,

Thanks very much for the feedback.

We have attempted to base our XML on the draft "Expressing Qualified Dublin
Core in RDF"
(http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/)  In
section 2.3.8 the recommendation for modeling the DCQ URI encoding scheme is
to use the rdf:resource attribute.  This makes sense because rdf:resources
are by definition URIs, and we need to preserve the fact that
mailto:[log in to unmask] is a URI, as opposed to some other type of
identifier, which could occur for different records.  You could encode the
agentidentifier like the following, while still preserving all of the
semantics:

<dca:agentidentifier>
  <dcq:URI>
    <rdf:value>mailto:[log in to unmask]</rdf:value>
  </dcq:URI>
</dca:agentidentifier>

but <dca:agentidentifier rdf:resource="mailto:[log in to unmask]" />
captures the same meaning more concisely.

Your suggestion to use the rdf:about attribute for the identifier
(<dca:Person rdf:ID="AUTHOR-1" rdf:about="mailto:[log in to unmask]">)
is also a good one, if (as Tim Cole pointed out) you get rid of the rdf:ID.
However, at least for our metadata, there are other considerations which
complicate this.  One being that we sometimes have multiple agentidentifiers
for a single person for a single record, such as one or more mailto
addresses and also an http home page for the person, plus in the future
there could be other identifiers such as found in name authority files.
Also, in many cases there is no identifier at all.  Because of this we
decided to just generate a local rdf:ID for the dca:Person, and then include
zero or more <dca:agentidentifier> tags for each identifier we could find,
such as mailto addresses or http home pages.  I think that if we ever
establish a privileged agent identifier, such as from a name authority file
of some type, then your suggestion of placing this identifier either as an
rdf:ID or rdf:about attribute on the top-level node for the agent would be
the correct way to go.

Anyway, hope this helps you understand our reasoning a little better.  This
is still a work in progress and a learning process for us, so other comments
are always welcome.

Kind regards,
        Tom

--
Thomas G. Habing
Research Programmer, Digital Library Initiative
University of Illinois at Urbana-Champaign
052 Grainger Engineering Library, MC-274
[log in to unmask], (217) 244-7809


Tim Cole wrote:
>
> On Fri, 13 July 2001, Jeffrey A. Young wrote:
>
> > On Thu, 21 Jun 2001 16:20:53 -0500, Thomas G. Habing <[log in to unmask]>
> > wrote:
> >
> > >up to date sample of one of our metadata files is available at
> > >http://dli.grainger.uiuc.edu/uiLIb/05_lecuyer_full.met
> >
> > Here is a snippet from the example listed above:
> >
> > <dca:Person rdf:ID="AUTHOR-1">
> >  <dca:agentname>
> >   <dca:FNF>
> >    <rdf:value>L'Ecuyer, Pierre</rdf:value>
> >   </dca:FNF>
> >  </dca:agentname>
> >  <dca:agentaffiliation>Université de Montréal Département d'Informatique
> et
> > de Recherche Opérationnelle C.P. 6128 Succ. Centre-Ville, Montréal PQ H3C
> > 3J7 Canada</dca:agentaffiliation>
> >  <dca:agentidentifier rdf:resource="mailto:[log in to unmask]" />
> > </dca:Person>
> >
> > I would expect the dca:agentidentifier's URI to be listed as the element's
> > value rather than an rdf:resource attribute. In other words, we should be
> > able to represent DC Agents independent of RDF.
> >
> > On the other hand, it might make sense to replicate the agentidentifier
> URI
> > in an rdf:about attribute in the dca:Person element. Here are the proposed
> > changes:
> >
> > <dca:Person rdf:ID="AUTHOR-1" rdf:about="mailto:[log in to unmask]">
> >  <dca:agentname>
> >   <dca:FNF>
> >    <rdf:value>L'Ecuyer, Pierre</rdf:value>
> >   </dca:FNF>
> >  </dca:agentname>
> >  <dca:agentaffiliation>Université de Montréal Département d'Informatique
> et
> > de Recherche Opérationnelle C.P. 6128 Succ. Centre-Ville, Montréal PQ H3C
> > 3J7 Canada</dca:agentaffiliation>
> > <dca:agentidentifier>mailto:[log in to unmask]</dca:agentidentifier>
> > </dca:Person>
>
> We had gone back and forth ourselves on whether mailto: link was better as
> content of agentidentifier property node or as the attribute value of an
> rdf:resource or rdf:about attribute.  Your logic that including mailto: link
> as node content is better to insure independence from RDF sounds good to me.
> In addition, there still seems to be a natural temptation when parsing
> unfamilar XML schemas to focus on node content more than attribute values,
> so expressing mailto: link as content might increase likliehood it will be
> included in indexing, transformations, etc.
>
> We did consider including mailto: link as an rdf:about attribute value for
> the typed node (in this case dca:Person) as you suggest.  The argument
> against doing it that way is the consideration that current RDF Model and
> Syntax doesn't allow for both a rdf:ID and rdf:about attribute on the same
> typed node.  You can legally have:
>
> <dca:Person rdf:ID="AUTHOR-1">
> or
> <dca:Person rdf:about="mailto:[log in to unmask]">
>
> But the following is NOT legal in RDF (at least not when using dca:Person
> the way we're using it):
>
> <dca:Person rdf:ID="AUTHOR-1" rdf:about="mailto:[log in to unmask]">
>
> SiRPAC gives parse errors for the last example.  Of course one can argue
> that our use of the rdf:ID in this case is rather trivial, in which case it
> might be better to drop rdf:ID attribute in favor of using rdf:about for
> mailto: link.
>
> By the way, another comment we got back on all of this mentioned that the
> DCMI Agents working group has not been very active of late and that it might
> be better to go with vCard which has gained a fair amount of widespread
> acceptance, at least for the time being.  We're still mulling that
> alternative approach over.
>
> Thanks for the feedback.
>
> Tim Cole
> Library, University of Illinois at UC