Mikael-

A couple of concerns with interpretations your suggesting for your DCQ/RDF
implementation are embedded below.

----- Original Message -----
From: "Mikael Nilsson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, June 17, 2002 12:44 PM
Subject: Re: LOM RDF binding effort


> Hi again!
>
> Ok, I'll try to outline some of my thoughts regarding the DCQ/RDF work
> from my experience with the LOM RDF binding.
>
> 1. First is a question regarding some of the elements:
>
> It seems obvious to me that all of
>
> dc:creator
> dc:publisher
> dc:othercontributor
>
> are rdfs:subPropertyOf dc:contributor. I am aware that this is not
> specified in either DCMES or DCQ, but anyway... shouln't this be modeled
> in the schemas?
>
> The same would apply to dc:source, that would seem like a dc:relation.

Many communities make distinctions between dc:creator, dc:publisher, and
dc:contributor such that all three are non-overlapping distinct properties
(e.g., read CIMI Guide to Best Practice for Dublin Core,
http://www.cimi.org/public_docs/meta_bestprac_v1_1_210400.pdf). In our work
at Illinois with creating metadata for articles published in selected
sci-tech journals, we also found it useful to make a clear distinction
between source and relation. In those environments at least creator and
publisher are definitely not subproperties of contributor, and source is not
a subproperty of relation. While, there might in certain circumstances be
some reason to want hierarchical sub-groupings of the 16 top-level DC
elements, that has definitely not been practice to date and is not done in
the current dc namespace. Also, there is of course no element in the dc
namespace called othercontributor.

It would adversely affect interoperability to make the assumptions you
propose, and it definitely would cause confusion to invent a new dc element,
especially one unlikely to ever be vetted by DCMI. You could of course
invent your own namespace with such additional constructs to group dc
elements, and then describe it using RDFS, but you shouldn't try to rewrite
the established DC namespace to fit your model. Given that battles over
super-elements such as the once proposed dc:agents have largely been fought
and resolved already, I'd suggest that making the assumptions you list would
just be confusing to others trying to integrate your DC with someone else's.

>
> 2. No elements make use of rdfs:range. I know it is not currently
> possible, as they can take container values as well as literals. But
> still, wouldn't it be natural for dc:title to have Literal range.
> Don't you regard this as a potential problem? And what kinds of
> solutions have you considered? Could, for example, the RDF specs be
> interpreted to mean that Containers of Literals can be used instead of
> Literals?
>

My understanding of Literal in RDF context (i.e., from model and syntax
spec) is anything that doesn't contain a resource -- thus could contain non
alpha characters, sub markup, MathML, etc. If that's what you mean, then
that doesn't seem overly restrictive, although one could argue for the
potential value of containers (as you suggest) and/or things like subtitles
being resources (e.g., consider various specific kinds of titles supported
by MARC). However, draft XML schema for simple DC and several of those being
considered for DCQ go further than the RDF Literal restriction and actually
prohibit any kind of sub markup at all within any DC element. The XML schema
may be the more restrictive here, in which case adding RDFS:Range limits
would just be confusing.

> 3. There is a very direct semantical relation between dcterms:issued and
> dc:publisher. What if I have tho publishers and two publication dates?
> The same with dc:creator and dcterms:created. In LOM, there is a
> substructure of the Contribute element, which allows a date as a
> qualifiers, so to speak. This is the most obvious problem area in the
> current LOM RDF binding. Have you thought of that?
>
All DC elements are repeatable, and this should not be precluded by any
DCQ/RDF schemas developed for general purposes. We've experimented with use
of RDF containers to help show relationships between repeated DC elements.
Jury is still out as to whether that's a necessary/desirable thing to do.

> 4. What about values that are from RDF vocabularies? There are no
> examples that use such constructs. In the LOM RDF binding, we use for
> example dc:subject pointing to taxonomy terms from RDF vocabularies
> (where each term has a URI). Isn't that a much better way than to encode
> all information in the metadata instances?
>

Yes, I've seen this. I'll try to find pointers to examples.

> I'll see if I can find some more points... I'll be back!
>
> /Mikael
>