At 03:04 PM 8/16/2001 +0100, you wrote:
>Oh yes, I agree, and I understand your point made in the previous message
>that all the descriptions of a uniquely identified term, however they may be
>distributed in physical files in different physical locations, are all tied
>together by the URI for the term they are describing - and it's _that_
>relationship rather than the physical distribution of the descriptions which
>EOR is working with.

Quick (but important) clarification... exchange EOR with RDF in the last
sentence.  While I have a certain affinity towards EOR :) there are many
other RDF toolkits out there that can serve as the basis for what we're
calling registries (others might simply be calling these databases of RDF
content).  The important things are the cross community agreements and
"registration" of these schemas simply by writing them to the web.   The
registry database might provide a convenient way of searching and browsing
these schemas, however its actually declaring these in a consistent manner
that's important.  Similar examples to google and actually web pages.  Its
the web pages that make google possible, not the other way around.

>I was making the point that in various exchanges (which were off this list),
>my understanding - and this may be where I'm going wrong as I'm still fairly
>new to this stuff...;-)  - was that we were arriving at a position where
>there was a one-to-one correspondence between a namespace and an RDF Schema
>representation which declared/defined the terms in that namespace. One
>consequence of that one-to-one correspondence was that the namespace URI
>_might_ serve as a "locator" for an RDF Schema instance describing the terms
>in the namespace.

Correct.  But this doesn't preclude others from saying additional things
about the terms (e.g. annotation) defined in a namespace (such as different
human readable labels, different definitions, if they support some term in
an application, etc).

...(content removed)...

>However, _if_ the namespace URI is also (potentially at least) to act as a
>_locator_, then it can only locate _one_ RDF Schema instance i.e. there is a
>"primary" (for want of a better word!) instance to which the namespace URI
>might serve as a locator, but there are other RDF Schema instances (the
>translations of that primary instance) - which are all good, valid
>descriptions of the namespace - which are _not_ located by the namespace
>URI.

Ahh.. I see your point.  Thanks for restating this, you are correct.  While
the URI in one case might be used to retrieve something off of the web
(e.g. http GET), in another case its simply a key which can be used to ask
other services what it "knows" about the identified resource.

>That was why I was returning to the "typology of schemas". Rather in the way
>that "application profiles" can be seen as containing "annotations" of the
>term definitions in namespace schema (or additional metadata about the terms
>in the namespace schema), providing information about real world use of
>those terms, so "translated namespace schema" might also be seen as
>"annotations" of those "primary" term definitions?

The 'primacy' is in term of the URI. Everything else (in sort) can be
viewed as "annotations".  Who can say what about these URI's are
unbounded.  In this case we're talking about 2 characteristics people are
trying to say things about these URIs... rdfs:label and rdfs:comment, the
values of which may be encoded in different languages.  Next we'll be
talking about xx:status or xx:equals.  And I might for my own purposes talk
about xx:usesAllTheTime (or whatever...).  Which annotations you
(individual, community, etc.) chooses to trust, however, are dependant the
particular goals and desired outcome.  In terms of the translations, I can
very well imagine that some additional DCMI board (usage?) might define
which might be considered the "official" DCMI translations.

Given this, the purpose of the registry group then is not to define which
is the "correct" description, but provide guidance as to which properties
and classes it wants to in essence "privilege" (e.g. give special
preference in an application for serving a particular set of needs) for
supporting the DCMI registry service.

 From http://dublincore.org/groups/registry/purpose-20010511.shtml it seems
the following are important:

so for phase 1 out would suggest:

so for all DC defined classes and properties, the following seem useful:

- all rdfs: vocabularies (label, comment, subProperty, etc.)
- a xx:status property with some yet undermined values
- a xx:usedBy property (to ground this in terms of a particular Application
Profile)
- a xx:practice (used for describing best practice)

also it seems like 2 new classes need to be established

- Schema (which may turn out to be eor:Schema)
- Profile (which may turn out to be eor:Profile)
- agreements on the vocabularies for describing Schemas and Profiles (which
may be DCES)

and phase 2:

(based on "Other Requirements" in document):

- xx:equivalentTo (for supporting cross walks... may turn out to be
webont:equavalentTo)
- xx:usedIn (to define relationships from dc:terms to examples)

Again, please remember.. not all of these properties need to be included in
the actual DC* schemas.  Simply agreeing on the URI for terms allows for
these different files to be merged together.

--eric