On 2002-06-04 16:52, "ext Thomas Baker" <[log in to unmask]> wrote:
> On Fri May 31, Patrick wrote:
>> We need a way to relate a term to resources which define it. And
>> we should use rdfs:isDefinedBy (or a subproperty of it) to do this,
>> but that resource is not a namespace. It might be an RDF schema.
>> It might be an HTML instance with prose for humans. It might be
>> text. Whatever.
>
> This is why rdfs:ns would work alot better for me.
But I feel that rdfs:ns misses a very critical point -- namely
that *namespaces* per their function in XML simply do not exist
in RDF. They have no formal representation or semantics in RDF.
And furthermore, if a given URI which denotes an RDF schema that
defines some set of terms happens to do double duty and also
be used as a namespace URI, it is not the *namespace* that is
defining the terms, it is the resource denoted by the URI that
also is used as a namespace prefix.
A *namespace* is nothing but *punctuation*. That's it. It describes
nothing.
If folks decide to allow a namespace URI to denote some "namespace
document", well, they're free to do so, but the view that there
is a 1:1:1 relationship between a term, a namespace, and the
complete definition of that term defined by some resource
sharing identity with the namespace is (forgive me) naive and
short sighted.
A given term may be used by multiple functional vocabularies,
where each vocabulary has its own identity seperate from any
URI intesection with the term, and a term may be defined by
any number of separate schemas.
Managing complex families of ontologies with multiple versions
and internationalization and locale variations requires a far
more modular organization than the simplistic approach of
one term, one namespace, one schema.
> If rdfs:isDefinedBy is being used (in effect) like rdfs:ns,
Perhaps by some, but not by all, and the present definition
of the semantics of rdfs:isDefinedBy does not constrain it
to such a narrow usage.
> it seems we might sometimes still need a pointer from an
> individual term declaration to a canonical source document
> (in this case, in "prose") in the form of something like the
> differently defined rdfs:isDefinedBy Patrick wants?
Exactly. We need only one property, rdfs:isDefinedBy which
relates a term to a defining resource, and since we have the
URI of that resource, we can describe that defining resource
however we like.
We can say what it's MIME encoding is, what role it plays
(a'la RDDL), where it might be accessible (if the URI is
not a URL), what it's XML PUBLIC identifier is, etc. etc.
Then, an application can choose which defining resources it
can or wants to reference.
> In Roland's schema at
> http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/Schema/A/dc
> terms
> the arcs
>
> | <dc:source
> |
> rdf:resource="http://www.dublincore.org/documents/2000/07/11/dcmes-qualifiers/
> "/>
> | <dc:source rdf:resource="http://www.dublincore.org/usage/decisions/"/>
>
> point to a single source (prose) file for the entire RDF
> schema, as a whole. However, I should think that as the
> number of terms and related namespaces increases, such a
> document-oriented pointer -- from one RDF schema document
> to one prose document -- would become increasingly less
> useful for locating the "source" resources that define any
> particular term.
>
> Already in
> http://www.gmd.de/People/Thomas.Baker/usage/terms/dc/ the
> terms defined come from two namespaces -- as a document,
> it replaces both http://dublincore.org/documents/dces/ and
> http://dublincore.org/documents/dcmes-qualifiers/. And it
> is not difficult to imagine the more extreme cases Patrick
> (I believe) has in mind, where a schema uses terms from
> more than two namespaces.
Exactly. This is the difference between a vocabulary and
a namespace. It is the functional vocabularies that are of
interest, not the trivial punctuation that might make
serialization of commonly managed terms more convenient.
We care about the DC vocabulary, which includes terms
from more than one namespace, and those terms are defined
in various ways, in various encodings, for various purposes.
Namespaces simply do not fit into the organizational equation.
They are just a convenience for the XML serialization. That's
all. Any correlation to a namespace URI and a vocabulary is
an illusion -- or a personal preference by someone who controls
all the defining content (which more and more is the exception,
not the rule).
Folks really need to stop equating namespace with vocabulary.
Despite historical coincidences, they are not the same.
> In the RDF schema of DCMI terms, then, might it not
> be helpful to have a pointer to the precise source of
> a definition in the canonical prose document, such as
> http://www.gmd.de/People/Thomas.Baker/usage/terms/dc/#title-003
> (historically, the latest version of a term from
> the http://purl.org/dc/elements/1.1/ namespace) or
> http://www.gmd.de/People/Thomas.Baker/usage/terms/dc/#medium-002
> (a term from the http://purl.org/dc/terms/ namespace)?
>
> Such precision might not be necessary in an informational RDF
> schema defining "just the current" elements in English for
> use in general-purpose RDF applications, as Roland is doing.
> But would such a pointer not be more important in an RDF schema
> of the elements defined in Japanese? How else would one point
> from a term declaration in Japanese back to the historically
> exact English wording upon which the translation was based?
I agree this is very important knowledge about resources, for which
dc:source seems well suited. Though this is knowledge about
the defining resource of a term, not necessarily about the term
itself.
> Would we not, then, need to ensure that
> each successive historical version of a term
> declaration has a unique identifier, such as
> http://dublincore.org/usage/terms/dc/#medium-002 or even
> http://purl.org/dc/terms/medium-002?
This is an interesting question from the viewpoint of
knowledge management. Do we want to reify all statements,
and then define their source and historical relations?
Of course, if we did so, we wouldn't need rdfs:isDefinedBy,
since we could easily obtain such information automatically
from the provenance captured in the reified statements.
I think it's probably sufficient to manage at a coarser
level of resolution, namely the schema, and then just
relate the terms to the schemas and define the historical
relationship between the schemas.
Each schema would have some functional significance, which
justifies its individual management, which may or may
not equate to the entire functional vocabulary, or perhaps
to a clear sub-component of that vocabulary. But in any
case, namespaces should be a minor or non-existent factor
in deciding where such partitioning occurs.
Cheers,
Patrick
--
Patrick Stickler Phone: +358 50 483 9453
Senior Research Scientist Fax: +358 7180 35409
Nokia Research Center Email: [log in to unmask]
|