xml-dev - Re: RDF and Resources

[Dan Brickley <Daniel.Brickley@bristol.ac.uk>]

Interesting point. The RDF spec says...

> > not directly accessible via the Web; e.g. a printed book. Resources 
> > are always named by URIs plus optional anchor ids (see [URI]). 

...when it perhaps ought to say "always named by URI References", per
section 4.1 of the RFC. 

I believe this is a confusion rather than a bug in the spec, in that
nothing I can find in either doc tells us that the things picked out
using URI References, ie. the #'d view into the retrieved object, cannot
themselves be resources. If they have identity (cue separate debate)
they're resources. And hence RDF describable.



Some excerpts from ftp://ftp.isi.edu/in-notes/rfc2396.txt

 Uniform Resource Identifiers (URI) provide a simple and extensible
   means for identifying a resource. 
[...]
   Resource
         A resource can be anything that has identity.  Familiar
         examples include an electronic document, an image, a service
         (e.g., "today's weather report for Los Angeles"), and a
         collection of other resources.  
[...]
4. URI References

   The term "URI-reference" is used here to denote the common usage of a
   resource identifier.  A URI reference may be absolute or relative,
   and may have additional information attached in the form of a
   fragment identifier.  However, "the URI" that results from such a
   reference includes only the absolute URI after the fragment
   identifier (if any) is removed and after any relative URI is resolved
   to its absolute form.  Although it is possible to limit the
   discussion of URI syntax and semantics to that of the absolute
   result, most usage of URI is within general URI references, and it is
   impossible to obtain the URI from such a reference without also
   parsing the fragment and resolving the relative form.

      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

   The syntax for relative URI is a shortened form of that for absolute
   URI, where some prefix of the URI is missing and certain path
   components ("." and "..") have a special meaning when, and only when,
   interpreting a relative path.  The relative URI syntax is defined in
   Section 5.

[...]
 the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed.  As such, it is not
   part of a URI, but is often used in conjunction with a URI.




So... on my reading...

--- the URI is the bit before the # in a URI or URI Reference
--- the entire 'thing' picked out by a URI Reference might still be a 
	resource and have 'identity' (and might eg. have a first-class
	URI in another scheme, eg uuid: or urn:). Even if just a section
	of a larger object (video frame etc).
--- for any URI reference, there are potentially two objects (resources)
    implicated; the one picked out by the URI proper, and the one picked 
    out by the URI reference, if there is an optional '#'.
    RDF uses the latter when the #foo is present. The Web doesn't give 
    a name to the relationship between these two things, though the 
    Web Characterisation activity seems to be making a good start in 
    that direction.

I see nothing in this to suggest that that RDF can't describe bits of
non-XML content, since those components for eg might well have URIs
(eg. urn, uuid...) of their own. What I do see is a rather ugly glitch
(doubtless motivated but still scary) in the section of the URI RFC
which defines fragment identifiers:

4.1 tells us:

	The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.


This is gross as it relativises the semantics of frag identifiers
to the mime time of the object as retrieved. Since that is itself a
(possibly time-sensitive) function of content-negotiation between client
and server, fragment identification issues get tangled up with
possibility of the server offering multiple
(language/format) negotiable versions or renderings (or manifestations
-- pick your terminology) of the same object.

When this wierdness in web architecture is cleared up, and the different
renderings available (eg. over http, http-ng) are more explicitly
differentiated, RDF and XML will be living in a happier less ambiguous
world. 

Dan

 On Sun, 6 Jun 1999, Paul Prescod wrote:

> RDF's definition of resource seems to be incompatible with the URI
> specification that it references:
> 
> > All things being described by RDF expressions are called resources. 
> > A resource may be an entire Web page; such as the HTML document 
> > "http://www.w3.org/Overview.html" for example. A resource may be a 
> > part of a Web page; e.g. a specific HTML or XML element within the 
> > document source. A resource may also be a whole collection of pages; 
> > e.g. an entire Web site. A resource may also be an object that is 
> > not directly accessible via the Web; e.g. a printed book. Resources 
> > are always named by URIs plus optional anchor ids (see [URI]). 
> 
> According to RFC 2396, a resource is something addressable by a URI
> (without fragment identifier) -- a complete HTML or XML document, not a
> part of it.
> 
> Also, I find it interesting to note that RDF does not seem to be able to
> attach metadata to components of things that are not XML: frames of a
> video, records in a database, paragraphs in a Word document and so forth.
> We need the ability to do so.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)