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

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

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

True, but to a certain degree, alot of the "hacks" exist because
some folks simply deny that there is a problem -- or because
the problem doesn't impact their own closed application they
don't want to be bothered fixing it.

We have to find a balance between getting the job done, as
present day needs demand, but also doing things right, and
progressing towards better ways of doing things.

Yes, people will hack stuff today. That's to be expected, and
in many cases encouraged. But we have to be careful which hacks
we allow to become standards. Some represent innovative solutions
that can improve web architecture. Others are short-sighted
house-of-cards tricks that will cause no end of woe if broadly
adopted.
 
Using namespace URIs to denote "namespace documents" is IMO
one of those latter hacks that glosses over a signficant
conflict between XML and RDF naming models and the different
roles that URIs play in the web versus the semantic web.

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

You are confusing role with identity. Yes, a person can be a son, a father,
an employee, a boss, a baseball player, etc. etc. but its still the *same*
person.

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

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

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.

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

Eh? I consider it to be the primary use case. And in fact, the
only valid use case.

In what way do you see it as extreme.
 
>> 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.

Well, let's not get into the issue of the uselessness of DC for
strongly typed metadata interchange...

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.

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

No, the problem is that folks want URIs to denote more than
one thing.

Another problem is that folks want it to be OK to guess some
relation between a term URI and some vocabulary URI, and use
the latter to retrieve knowledge about the term (which is itself
a reasonable thing to want to do) yet RDF provides no such
formal relationship with regards to the term URI itself; therefore
any application which attempts to do that is *untrustworthy*
with regards to the truth of the augmented graph.

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

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


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

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.

And here we are at the crux if the issue, how does that application
know how to *reliably* obtain additional knowledge about URI
denoted resources in an RDF graph? The present hacks (and they
*are* hacks) work for some cases, but are not based on the
actual web architecture or on principles that are scalable and
URI neutral (they force you to use particular URI schemes and
other steps to get them to work.

But in the RDF/SW world, the only way you can obtain additional
information about a URI denoted resource is to query one or
more external sources based on that URI. The URI itself cannot
and does not tell you where those external sources are. So we
need some other mechanism for such knowledge discovery.

I have no problems with folks tinkering around with RDDL and
namespace accessible schemas -- *so long as* that does not
prevent work on a more optimal long term solution.

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

Many feel the same way about URIs.

Global and temporal uniqueness comes at a price.

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

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.

Cheers,

Patrick


> 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 Thursday, 6 June 2002 07:11:36 UTC