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

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

> But e.g. if a mailto: URL is used to denote both a person and 
> a mailbox
> on some server, if you then say
> 
>    mailto:john.doe@abc.com rdf:type #baseball_player .
> 
> are you saying that John is a baseball player, or that the mailbox is
> a baseball player?!

Right. BTW, this is an excellent use case for my representative
approach. A workflow app can address the target resource using it's
representative resource for a certain domain of roles (such as point of
contact via email). I'm not sure which is the best way to model this,
things get complicated pretty quick. I'm not really into n3 but there it
goes anyway:

person:john.doe rdf:type #baseball_player ;
        rep:email mailto:john.doe@abc.com .

rep:mailbox mail:address "john.doe@abc.com";
                  rep:of person:john.doe .

I think this gets complicated because the RDF graph is directed, thus
it's necessary to have an edge coming from both A to B and B to A. 


> It is a fundamental principle of the RDF MT that a given URI denotes
> one and only one thing in the universe.

Yes. But that unique thing can have many roles!

 
> So using a namespace URI to denote both the collection of names and
> a namespace document is contrary to RDF semantics and simply an error.

Ok, I'm not arguing for that anymore; just want the best solution I can
get instead of using namespaces.


> But that is still beside the point. If the URI has a 1:N mapping
> to things in the universe, then we can *never* be sure what the
> subject of the statement is.

Yes, I can see that now, perhaps the representative approach breaks due
to this. The only way it can work is to be in the core of the language,
maybe depending too much on rdfs:domain:

mailto:john.doe@abc.com foo:profession #baseball_player .

foo:profession rdfs:domain #Person.

Since mailto:john.doe@abc.com is of type mailbox and not person, one
could check if the statement validates against what the mailbox
represents. Oh well...


> >>> 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".
> 
> I fully agree. http: URLs should *always* resolve to a web resource.
> 
> If you have a resource that is not web-accessible, you should *not*
> denote it with an http: URL.

Namespaces for example, in both plain XML and RDF...


> Of course, to some folks, that's either blithering nonsense or
> heresy (or both)  But hey, it's a free world, and they're
> free to be wrong ;-)

The problem is, most people are introduced to namespaces while using
URLs, which makes things confusing.


> >>> 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.
> 
> I'm not sure I follow you -- unless you mean that in RDF, URIs
> are fully opaque, including the scheme, in which case I agree
> that this is an issue.

Yup; my English.


> But URIs *should* remain fully opaque to RDF. An application,
> however, may choose to examine the structure of the URI to
> determine what it can/should do with it.

But without adding to RDF semantics. Perhaps this is why some people
disliked URI schemes as a solution to the datatypes issue.


> I think we perhaps do agree about contextual meaning, and it's
> importance. Hopefully my comments above have clarified for you
> what I was talking about -- that a URI cannot denote more than
> one thing in the universe, even if that thing has many classifications
> and roles.

Yes we do agree on contextual meaning; I also meant roles etc.,  but it
gets confusing for as mortals...

Indeed your comments where very helpful in making things clearer. Thanks
for your patience!

Cheers, 

Manos

Received on Thursday, 6 June 2002 08:44:37 UTC