Re: rdfs:isDefinedBy (Was Re: Representing DCMI semantics as RDF schemas versus Web pages)

On 2002-06-05 12:46, "ext Manos Batsis" <m.batsis@bsnet.gr> wrote:

> 
> 
> Hi Patrick,
> 
> 
>> -----Original Message-----
>> From: Patrick Stickler [mailto:patrick.stickler@nokia.com]
> 
>> On 2002-06-05 2:26, "ext Bill de hÓra" <dehora@eircom.net> wrote:
>> 
>> 
>>> Here's the question: Are XML namespaces RDF resources? If a
>>> collection of names identified by a URI reference can be an RDF
>>> resource, then an XML namespace can be an RDF resource.
>>> 
>>> Bill de hÓra
>> 
>> Obviously, anything in the universe that we can give a URI to
>> can be a resource, so in that regard, a namespace can be
>> an RDF resource. Sure. But then that URI should not denote anything
>> *but* the namespace.
>> 
>> If the URI that is adopted as a namespace prefix already
>> denotes something else, such as a vocabulary, or a schema,
>> or other kind of resource, then we introduce ambiguity into
>> the SW.
> 
> 
> I may not have much hands on experience using RDF in my applications (with the
> exception of simplistic metadata profiles like DCMI), but I really cannot
> understand how one can trust my application on processing metadata when it
> encounters a vocabulary it doesn't know, without the use of  namespace URIs
> that point to RDFS documents. How can this automation be applied to knowledge
> distributed over the internet without this mechanism? I always had the
> impression this is one of the key features of RDF and the way it deals with
> namespaces.
> 

The key requirement here is to be able to access knowledge about
a resource based on the URI of the resource. I.e., I encounter
some term and need to find out what it means.

Well, there is no way to get from the URI to the namespace based
on the URI itself -- both because URIs are opaque to RDF semantics
and also because the partition between namespace prefix and local
name is lost and not reliably retrievable.

So, sticking some RDF schema on a server under the namespace URL
won't work anyway.

Likewise, even if you use a property such as rdfs:isDefinedBy,
where do you expect that statement to be? Well, of course in
some schema *defining* the term. Duh. Like that really helps
some application find the definition based on the term's URI
alone. Nope.

What is needed is a globally distributed knowledge base which
allows one to obtain such defining knowledge about a URI.

Yeah, that's a pretty big order. But recent work such as DDDS
and FreeNet suggest it is doable.

But there is *no* reliable way to get from a URI to a namespace,
and hence namespace document or schema.

Until a global knowledge base exists, folks should expect to
have to hand-feed their systems with schemas as required. At
least insofar as bootstrapping knowledge is concerned.

>> It is no better than using a mailto: URL to denote a person.
>> How do we then differentiate between the properties of the
>> mailbox and the person?
> 
> Using an RDF property that unambiguously categorizes the resource as the
> actual target or an appropriate representative of the target as far as a
> certain application is concerned ( or a class of applications, that can also
> be automatically understood using RDF and this method ).

No thanks. I'd rather have all of my SW applications agree on what
a given URI mean, rather than different applications assigning
different meaning.

Yes, I know that's the TM way, but I don't subscribe to contextualized
interpretation of URIs.

I consider contextual meaning to defeat the whole purpose of URIs.

>> How do we differentiate between the properties of the namespace
>> and some other resource with which it shares its URI.
> 
> I'm not sure what exactly you mean by namespace here ;-)

A URI can denote anything in the universe. An XML Namespace
is technically nothing more than a collection of names, or
a partition within which names reside, so as such, it can
be named and described in RDF.

However, if the URI we use to denote that collection of names,
which is an abstract entity, is also used to denote e.g. an
actual instance of an RDF schema, how do we differentiate
between the two? If I say

  {someURI} dc:creator "John Doe" .

how do we know what John is the creator of? Did he conceive of
and define the collection of names, or is he the author of
a specific schema providing a formal definition of that collection
of names? They may not have the same creator!

>> And if a namespace URI denotes "a collection of names" then
>> it is an abstract resource -- not a schema, or namespace
>> document, or any other retrievable resource.
> 
> Yes! That's why, IMHO, non retrievable URIs should not be used (with some
> exceptions; 

Then we cannot talk about abstract and non-digital things
in the universe with RDF. I expect that once the SW hits
critical mass, there will be far more URIs denoting abstract
things than web-accessible things. Actually, that's probably
already the case for the Web, since *every* element, attribute,
and similar vocabulary term is an abstract resource.

> even then there should be a property identifying that resource as
> non-retrievable).

Or, rather, that URI should be expressed with a URI scheme
which has explicit non-dereferencable properties.

E.g. http://ietf.org/internet-drafts/draft-pstickler-voc-01.txt

> 
>> So if we stick
>> some schema, say, at that URI, we again introduce ambiguity,
>> since we can't differentiate between the properties of the
>> schema and those of the collection of names. And let's not
>> forget that a given collection of names might be defined
>> by mulitple schemas in various encodings/languages.
>> 
>> While historically many of the more visible vocabularies
>> have had a 1:1 correspondence with a namespace, i.e all
>> terms in the vocabulary are grounded in the same namespace
>> and the namespace URI also denotes the vocabulary, that is
>> not because of any inherent characteristic of namespaces
>> themselves and not IMO because that is the "right" way
>> to do things.
>> 
>> You could just as well have a vocabulary that has terms,
>> each of which is grounded in a separate namespace, and
>> none of those namespace URIs denote the vocabulary. And
>> that is just as valid a use of namespaces as the first.
>> And in fact, in the case of complex families of ontologies
>> with multiple versions and regional/locale variations,
>> the latter is precisely what is required.
>> 
>> Insofar as *web architecture* is concerned, the fact is
>> that namespace != vocabulary != schema != doctype, etc.
> 
> Yes. But what about "as far as RDF(S) is concerned? How will the RDF WG
> address this need?

That is an open question.

> 
>> Finally, if it is argued that namespaces are RDF resources
>> and they have a special relation to the terms which are
>> grounded within them, then RDF is behaving rather badly
>> by discarding the structural partition between namespace
>> prefix and local name or not automatically defining such
>> a relation in the graph. The concatenation-based transformation
>> from qname to URI employed by RDF clearly reflects a view
>> that the namespace is irrelevant, and all that matters is
>> the URI. 
> 
> But namespace information, when used to point resources such as RDFS
> documents, is irrelevant to the graph. They are only used to find the
> information needed to complete the graph, no?

Well, there's no problem with RDF applications locating
and assimilating additional knowledge based on existing
statements, in fact, that's where alot of the really
interesting stuff happens.

It's a matter of *how* the resources containing that
information are identified and the architectural
mechanisms employed.

The present "hack" of guessing the namespace of some term,
and trying to dereference some resource stored at the
namespace URI is inherently broken. It is not supported
by the existing web archtecture, nor by the RDF MT,
nor by any formal representation of namespaces or their
relationship to terms in the graph.

Making it work is all smoke and mirrors. It's a house
of cards design and we're in for trouble if folks
fail to come to grips with the fact that it's broken
and incomplete.
 
>> And I don't see namespaces or their relations to terms
>> formally defined in the RDF MT either.
> 
> Which is a major flaw in the spec, since another mechanism is not provided.

I would be very surprised if any such mechanism is provided
for under the present WG charter, since doing so would
require preserving the partition between namespace and
local name, and that is too great a change to include.

Do not expect any standard RDF mechanism for automatically
relating a term URI to its namespace in the RDF graph. It's
very unlikely to happen.

The best we can do for now is allow folks to use a property
such as rdfs:isDefinedBy to relate a term to a defining
resource, and then manually bootstrap that knowledge into
any system we're using.

Any system that attempts to guess that relation by parsing
the term's URI is *untrustworthy*. It may make for cool
demos and neat hacks, but such behavior is inherently
unreliable and not based on the existing specs.

>> The bottom line is that there are now two conflicting
>> global naming schemes on the Web: qnames and URIs.
> 
> Not necessarily. In my non-complicated and perhaps naïve view of things, once
> the following namespace declaration is in scope
> 
> xmlns:foo="http:www.bla.org/ns/foo"
> 
> Then foo:object should be just the XML way of denoting
> http:www.bla.org/ns/foo#object

Nope. Sorry. In RDF, that becomes

http:www.bla.org/ns/fooobject

No '#' is inserted to preserve the partition.

> However, this relationship was never addressed with a well defined
> solution/documentation by W3C, for example there's no unambiguous xml:id to
> serve this purpose.

True, but then, it's not really needed, since one can just
use UUIDs.

> 
> 
>> 
>> XML uses qnames. RDF and most other web technologies use
>> URIs.  And RDF/XML uses qnames simply as a hack, similar to
>> ENTITYs, just to get URIs into element and attribute
>> names, but disregards all structure and semantics defined
>> by XML for those qnames. Once you get to the graph, the
>> namespaces are gone. Poof.
> 
> Why is that bad?

Because the following two qnames represent 6 different names
in XML (two each for all three contexts of element name,
global attribute name, and element-specific attribute name
but represent only one URI in RDF:

   ns: urn:foo:bar   name: boo
   ns: urn:foo:b     name: arboo

which in RDF are just

   urn:foo:barboo

> 
>> I again assert, there are namespaces in the RDF model, and
>> namespaces are abstract things, not equivalent to schemas,
>> and therefore it makes no sense to specify a namespace URI
>> as the value of rdfs:isDefinedBy.
> 
> I can't argue that since using a property to explicitly point to an RDFS
> document would affect the graph to include information that may be considered
> irrelevant. However, in that case, the definition of rdfs:isDefinedBy as given
> at [1] is really misleading: " The property rdfs:isDefinedBy is a subproperty
> of rdfs:seeAlso, and indicates the resource defining the subject resource.".

I don't see anything misleading there, presuming you don't
expect the object of rdfs:isDefinedBy to only be a namespace
or RDF schema instance.

> 
>> If rdfs:isDefinedBy is supposed to point to a term's
>> namespace, then (1) it is not needed, since that information
>> can be retained from the RDF/XML and (2) it should have
>> a cardinality of 1 since of course, a term only has one
>> namespace. (so clearly, such usage is nonsense)
>> 
>> IMO rdfs:isDefinedBy should point to any resource that provides
>> definition of a term, regardless of encoding/language, and
>> it should explicitly *not* be a namespace (which is simply
>> an abstract collection of names). As to the nature of the
>> defining resource, just use RDF to describe it. Simple.
> 
> Absolutely. I see it as a way to point to documentation for us humans.

Great. Then we are at least agreed on the actual usage
of rdfs:isDefinedBy ;-)

Cheers,

Patrick


> Kindest regards,
> 
> Manos
> 
> 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 5 June 2002 06:56:08 UTC