suggestion new uri scheme??? for bnodes

Point of this message:
     One possible solution to the bnode attribute problem is not to have 
one (or two) but to use URIs. This was the idea in marks x-pointer 
solution, that noone else liked.
In essence the problem is we don't have appropriate URIs. I think it is 
arguable that we don't have appropriate URIs because, despite such a URI 
being in scope of 3986, there isn't any such scheme, which seems 
adequate motive for defining such a scheme.

Discussion in two parts, first about the scheme, then about xhtml 2



===========================
The Scheme
----------


As part of my Jena work, I'm thinking of implementing RFC 3986/3987 
(URI, IRI) and read the following text:

[[
    URIs have a global scope and are interpreted consistently regardless
    of context, though the result of that interpretation may be in
    relation to the end-user's context.  For example, "http://localhost/"
    has the same interpretation for every user of that reference, even
    though the network interface corresponding to "localhost" may be
    different for each end-user: interpretation is independent of access.
    However, an action made on the basis of that reference will take
    place in relation to the end-user's context, which implies that an
    action intended to refer to a globally unique thing must use a URI
    that distinguishes that resource from all other things.  URIs that
    identify in relation to the end-user's local context should only be
    used when the context itself is a defining aspect of the resource,
    such as when an on-line help manual refers to a file on the end-
    user's file system (e.g., "file:///etc/hosts").
]]


http://www.ietf.org/rfc/rfc3986.txt?number=3986

This got me thinking on whether a bnode identifier (with a slightly 
different syntax, e.g. local:name, where "local" is the URI scheme name 
and name is a string matching the path-rootless construct of RFC 3986), 
could be a URI in this sense.

The key text in a definition of such scheme would be:

[[
The local: URI scheme provides a method for constructing identifiers
in a uniform way, consistent with other identifiers, for resources
for which no other URI is known or appropriate, but which can be given
an adequate interpretation in some end-user context.
A "local:" URI is always interpreted in relation to the end-user 
context, and should not be used except where that context supports this 
scheme. This is similar to a file: URI without an authority component 
which should only be used where there is a contextual file system (the 
localhost); but differs in that the possibilities for the context of 
interpretation are less constrained.
]]

RDF documents would be given as the example end user context, merging of 
  multiple contexts could be discussed (the renaming function).
This could be done easily by giving each of the contexts to be merged a 
local: URI and then interpreting the local: URIs within context A as 
relative references to be resolved in relation to the local: URI of 
context A.


Context A:   local URI for context:   local:A/
   local URIs in context A
      local:a
      local:b


Context B:  local URI for context:   local:B/
   local URIs in context B
      local:a
      local:b

Merged context has local URIs
    local:A/a local:A/b local:B/a local:B/b

Also, renaming within a context (i.e. the graph isomorphism of RDF) can 
be discussed: i.e. it is always possible to substitute all references 
for local:a by local:newa where local:newa is unused, and the overall 
meaning is unchanged).

Hmmmm, by requiring renaming to leave the query and fragment parts 
unchanged, it would make the scheme usable for a wider range of 
applications.

=========================

XHTML 2
-------
If we wanted to pursue this approach, we then go ahead with XHTML2 with 
no solution for bnodes, and separately start up a scheme registration 
and see how it goes. If the scheme registration fails (which of course 
it might) we then revisit for XHTML 2.1 ...

It would be worth having a draft for such a scheme up pretty quickly so 
that it can be informationally referenced from XHTML 2 ...

Jeremy

Received on Thursday, 11 August 2005 07:39:39 UTC