RE: Documents, Cars, Hills, and Valleys - Some statements and proposals

Follwoing Dan's mail I would like to propose a set of statements about RDF in order to try and give some foundation to what we are discussing. Agreement or disagreement about the different points would at least help in finding where any miscommunication or misunderstanding is occurring.

Following this I make a couple of proposals for discussion.

Here are a set of statement I believe true about RDF:

1. An RDF resource is an abstractions or proxy for some 'thing'.

2. That 'thing' may or may not be a something that exists inside some computer system. i.e. the 'thing' may or may not be resolvable. example a web page is resolvable, the empire state building is not.

3. Each resource has an 'unique' identifier which is some string of bytes.

4. That the string of bytes IN NO WAY indicates the nature of the thing.

5. Overloaded behaviour : if the thing is resolavable then the identity of that resource is also the 'locator' for the real thing.

6. Given a resolvable resource locator (loc) and a resolution function ResF. ResF(loc) returns the stream of bytes/ a object handle etc that is the real thing.

7. It is the nature of the property assignements that give meaning and to an extent identity to the things we are talking about. Semantic interchange is achieved NOT by trying to magically understand the string of bytes that is the identifier, but by agreeement on the meaning of the relationships and properties of the 'identified entity'.

8. It is only through common agreement of arrays of bytes of identifiers that we can encode 'semantics' into our systems.  Some examples follow:

We have agreement on what rdf:type means. Now because we have a common understanding, proposed in a standard and adhered to by developers we have semantics. The string of bytes 'rdf:type' could be anything! Provided that we *agree* on 'what it means'.   

Thus I could have :, rdf:type, urn:standardsbody, rdfs:label, "The W3C"

And the identity of the resource is largely irrelevant, its the fact that its unique and the fact that there is common agreement on rdf:type and urn:standardsbody.

Some proposals:

It would be useful to have agreement on a property identity that allowed everyone to express clearly and unambiguously that a resource is a resolvable one.

What about clashes of identity?

Its quite likely in the example I gave above that a clash of identities could occur. What does this mean - does it mean we have a messy graph, does it mean we need to resolve semantic clashes - i.e. rdf:type urn:person and rdf:type urn:webresource are not compatible types for one resource. Do we need truly unique identifiers and a property of the entity which is a common handle or public identifier?

If I had to turn the last one into a real proposal I'd say that:

a reource is defined as 
I hope this is a constructive view on the problem we are discussing and that it somehow brings us closer to resolution. 



-----Original Message-----
From: Dan Brickley []
Sent: 30 April 2002 05:33
To: RDF-Interest
Subject: Re: Documents, Cars, Hills, and Valleys


OK, time out!

This thread has gone on plenty long enough for my taste.  How about we try
to give it some focus and closure. In particular, I think we should try to
focus on:

 - proposing textual revisions to specs (RDF MT, RDF syntax, URI -
   RFC2396, RDF Schema)

 - comparing implementation behaviour (pointers to code, tools etc)
   using concrete fully worked out test cases (instance data plus schema)

It's an interesting topic, I could just see the thread continuing on for
eternity without hope of resolution unless we try to achieve something
specific. We seem to revisit this theme periodically. I don't want to be
reading "What's the URI for a person" threads here in 5 years time! Which
means figuring out ways of agreeing, of agreeing to disagree, and agreeing
how our disagreements manifest themselves in the understanding of RDF/XML

I would like to see specific RDF/XML test case documents used as the focal
point of debate, and specific real world applications (digital library
systems, end user interfaces, queries) that illustrate the problem. If
there's a problem, let's try to pin it down to specific examples. This
means that when people write sample fragments of data, they should
probably take care to spell out the associated schema definitions
(rdfs:label/comment prose) for classes and properties used, rather than
assume the meaning is clear from the property etc names.

Anyone else want to try wrapping this up?



This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit or alternatively call
Star Internet for details on the Virus Scanning Service.

This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.

Received on Tuesday, 30 April 2002 07:57:26 UTC