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

> From: Patrick Stickler [mailto:patrick.stickler@nokia.com] 

> 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.

Ah, I see the problem. It's because you kicked the # out as you
corrected me below... That breaks both the use of IDs and the reliable
distinction of local-name and prefix parts of the URI. Why did that
happen anyway...

 
> 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.

A simpler way should have been possible. RDF will not be adopted for
it's complexity.


> 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.

Which brings down one of the major reasons to use RDF in the first
place. As Bill de hOra points out, ways of doing this will be
implemented whether good or bad because the spec will not cover the need
it was meant to cover. People *will* start using various "hacks",
perhaps with no compatibility between them.


> >> 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.

Depends on what you see as contextual meaning. Considering a property
that describes directed relationships between relatives, I am a son to
my mother and a brother to my sister. Context matters.

I also work for an IT company, sometimes being the point of contact for
clients. I represent the company as far as they are concerned.

RDF is able to describe the above relationships, including that I am not
that abstract resource that represents me or (even better) the
retrievable resource that represents me. It can also describe that
resource as a representative of mine, including the domain of functions
it can serve as such.


> >> 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.

An extreme use case.


> 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!

Yes I see the point. However, dc:creator should have appropriate
rdfs:range and  rdfs:domain defined. One of the two statements using
dc:creator should be reported as invalid.


> >> 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.

So, the problem as I see it, is that we are context blind.


> > 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.

Let me rephrase that to "non retrievable URIs should not be  used for
things non-web-accessible".

 
> > 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

I like URI schemes, but there are some conflicts because RDF semantics
about URIs are outside the URI thus far. 


> > 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.

Perhaps you have the implementor context in mind; I on the other hand,
have the author's context in mind. Besides, using UUIDs seems like using
a bazooka to shoot down a fly.


> >> 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.

Ah, now I get it. It's contextual meaning  of URIs that make the idea
bad for you in the first place. Sorry, we don't have the same opinion
here since, IMHO, contextual meaning is necessary to describe real life
relationships between things anyway.

Regards,

Manos

Received on Wednesday, 5 June 2002 08:37:30 UTC