Re: semantics and RDF(S)

At 09:34 AM 1/12/01 -0500, Dan Brickley wrote:
>While identity/naming/equality wasn't the only issue you raised, it is
>IMHO at the centre of most of the confusion we've seen, and a precondition
>for clarity on the other issues you mention. In my view you're
>right to be frustrated, but have the wrong target. The thing to clean up
>first is the general notion of URI naming on the Web; if we get that
>right, a crisper view of RDF should fall out more or less for free.
>
>In a nutshell: formalise URIs and you fix a bunch of stuff at once;
>formalise RDF and you'll still have to map it to a load of specs that have
>differing notions of URI, resource, URI reference etc.

Yes, please!!!

One of the enduring frustrations I feel is the issue of the relationship 
between URIs and resources -- is it 1:1-onto, or is it N:1?.  There appear 
to be quite firmly-held different opinions on this.  I've kind-of learned 
to muddle along without a clear resolution of this, but clarity would be great.

Over the past months I've also tried to jot down some ideas about this, 
drawing upon material from RFC2396 and other sources.  I'm not strong on 
this kind of formalism so they are inevitably very rough:  my thoughts, for 
what they're worth, are copied below.

#g
--


Fixed properties of any URI:
- URI has scheme name and scheme dependent part
- URI is associated with resource


Properties of resources:
- Resource instance may be abstract, or may have associated state
   (Do any schemes not allow state?)
- Resource may be passive or active (active => autonomous state change)
- Resource may support RES-GET  (retrieve value based on current state; may 
be parameterized)
- Resource may support RES-POST (change state)
   (Hypothesis:  other operations are specializations of these)

- resource is a (conceptual) mapping from its identity (URI) to some entity 
or set of entities.
   -- what is a "conceptual mapping"?


Variations of URIs:
- Association of URI with resource may be global (http:) or 
context-dependent (file:)
- URN: passive, support RES-GET, not RES-POST (fixed state)
- URL: scheme name identifies a way to do RES-GET and/or RES-PUT


Equivalence of URIs:
- string equivalence ("A"=="B")
- state value equivalence (RES-GET("A",p)==RES-GET("B",p)), for all p

   If RES-GET is not supported, then string equivalence is the only game in 
town.
   If RES-GET is supported, then string-equivalence => state-equivalence 
for globally scoped URIs.

   But (example due to Jonathan Borden):
   http://example.com/your-doctor  --> "John Smith"
   http://example.com/your-plumber --> "John Smith"
   indicates that state-equivalence =!=> string-equivalence,
   and should not be allowed of itself to imply other equivalences.

   But also note:
   string-non-equivalence =!=> state-non-equivalence.
   There is a higher notion of equivalence here,
   along the lines of "doing what I meant, not what I said".
   This might be revealed by RDF and inference rules.


Resource as "object":
- has two member functions:  GET and PUT.
- R.GET : Z -> E
- R.PUT : Z * E -> {}
- where R is resource, Z is arbitrary parameter(s), E is entity

- then RES-GET( U, Z )    == Deref(U).GET( Z )
-      RES-PUT( U, Z, E ) == Deref(U).PUT( Z, E )
   ('Deref' is function that maps URI to resource.)

- Model resource as triple:  < URI, GET+undef, PUT+undef >
   (GET, PUT are functions as above, being part of the resource.)


URI-references:
- Relative URI:  needs context to define full URI.
   (May be considered a syntactic sugaring device: context+relative-URI -> URI)
   (Another view (Joe K): URI-ref denotes a set of URIs, select by context)
   (String-equivalence =!=> state equivalence)
   (Question: is it always possible to distinguish syntactically relative 
from absolute form?)
     [I think not;  then 'file:name' could be local part of e.g. 
'host-resource://host/file:name'.]
   (Question: are any other URI schemes like file?)
- Fragment ID: is information separate from URI
   Advises request issuer how to deal with result of RES-GET.
   May be used as sub-resource identifier; sub-resource may be abstract,
     or may be associated with part of corresponding resource state, hence 
may be subject
     of RES-GET and RES_POST on the corresponding resource.
   (NOT used as part of any RES-GET or RES-PUT operation.)





------------------------------------------------------------
Graham Klyne                       Content Technologies Ltd.
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@mimesweeper.com>
------------------------------------------------------------

Received on Sunday, 14 January 2001 06:37:56 UTC