Rachel said:

> > I agree that if one uses a traditional database solution then the
content
> > and structure of a schema defining the DCMI vocabulary does not
> > necessarily become a non-issue, but the schema would certainly no longer
> > be 'co-terminous' with the DCMI vocabulary definition.
> > By illustration one
> > might decide to put some, all or variants of the data in the DCMI
registry
> > into a schema exported from that registry.

Roland said:

> My poor knowledge of English ....what is 'co-terminous'?

Errrr, I'm not sure it's just the language that's the problem, as I'm afraid
I wasn't completely sure what Rachel was getting at here!

What I _think_ Rachel is suggesting (my apologies, Rachel, if I'm
misinterpreting you!) is that a file containing RDFS-based
descriptions/statements which was generated by export from the information
in the RDBMS might not contain the same set of descriptions/statements as
the files which are at present maintained as native RDF/XML and which
correspond to the descriptions of the DCMI "vocabularies".

However, I _think_  the same is true for an approach based on indexing
RDFS/RDF/XML files which are maintained natively.....

As far as RDF is concerned, it seems to me (and I'm not completely sure
whether my understanding is correct so please take all of the following with
a large pinch of salt.....) there is no reason why _all_ the RDFS-based
definitions/descriptions of the DC-created and DC-related "semantic units"
(elements, qualifiers, resource type classes, classes for related encoding
schemes etc etc etc) could not be maintained/published in _one_ single file
("RDF schema"), even if they continue to be partitioned amongst several
different XML namespaces.

Without getting into the argument about what should or should not be
obtained on de-referencing a namespace name/URI, it would be perfectly
possible (it seems to me!) to redirect the three _separate_ DC namespace
URIs to a _single_ "RDF schema" file.

i.e. there is no necessary one-to-one relationship between a namespace and
an RDF schema (in the sense of the file containing the RDFS-based
descriptions/statements). And there is no necessary one-to-one
correspondence between a "vocabulary" and an "RDF schema".

It is simply a convention which has been adopted to manage the current RDF
schema files, albeit a useful one. And if it is enforced as a convention in
the present management of the native RDF/XML, then it could be enforced
equally in the export procedures which generate those files from an RDBMS.

Pursuing this a bit further....

These points (or very similar ones) were made by Patrick Stickler on
dc-architecture

http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0110&L=dc-architecture&F=&S=&
P=5782

and I think it's a pity that some of them got lost in the (quite separate, I
think) issue of what a namespace name/URI should or should not resolve to.

In a follow up to that message, Sean Palmer argued that namespaces do not
actually exist at the RDF level

http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0110&L=dc-architecture&F=&S=&
P=7211

It seems to me (again, please correct me if I'm wrong here) that at the
moment there is _no_ explicit description/definition in the DC RDFS/RDF/XML
schemas of the relationship between the various semantic units and the
"vocabularies" to which they "belong". In fact there is no
description/definition of those "vocabularies" as resources in their own
right.

That might seem a very odd thing to say, but I think that at the RDF level,
as Sean suggests in the message cited above, we are basing our inferences
primarily (entirely?) on an analysis of the URI for a semantic unit:

e.g. because the URI for a term begins with the string
"http://purl.org/dc/elements/1.1", then it is a member of the DC simple
"vocabulary".

This may be OK, but I think we do need to make this explicit somewhere.

Actually, just as an aside, I'm not sure we all agree on what the
"vocabularies" are! Which "vocabulary" does the term
http://purl.org/dc/terms/audience belong to? Is it the same "vocabulary" as
the term http://purl.org/dc/terms/spatial? If not, then even the suggestion
that we are basing our inferences on URIs is wrong and we really _do_ need
to be clear about how we are establishing these relationships!

One way of dong this would be to create explicit RDFS-based
descriptions/definitions of the DC "vocabularies" as separate resources, so
that we can then make explicit statements about them - without relying on
drawing conclusions from the strings which make up URIs. And then we can
create explicit statements about the relationships of individual units
(terms, qualifiers etc) to those vocabularies.

And although I've concentrated here on the RDFS representation of the DC
semantic units and their aggregates, I think all of the above applies just
as well to the management of this information within a relational database.

Cheers

Pete
-------
Pete Johnston
Interoperability Research Officer
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 323619    fax: +44 (0)1225 826838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/