RE: Resolving references against base URIs

Thanks for the further explanation.

I'm still concerned that there may be an architectural issue
insofar as RDF says how to resolve a relative URI reference 
consisting of only a fragment identifier.  

If RDF needs to treat rdf:about attribute values specially 
for its own reasons, then I'd say that RDF doesn't have to
identify the rdf:about attribute's type as a URI reference.
RDF can call the rdf:about attribute's value a string and
define its semantics.  

But once you call it a URI reference, I would think you are 
required to "inherit" all the defined behavior for such, and 
I'm still unconvinced that RDF should be able to define special 
interpretation for same-document references.  If this is the
direction the RDF WG wants to do, I think it would be best to
take this to the TAG where there are many more experienced
minds to consider this.

paul

At 18:15 2002 04 15 +0100, Brian McBride wrote:
>At 09:51 15/04/2002 -0500, Paul Grosso wrote:
>>At this point, it looks like we are all using different phrases
>>(not even sentences) in various specs to support different views.
>>
>>My view is that an RDF resource should be something of MIME type XML,
>>and anything of MIME type XML that does anything with XML Base has to
>>interpret things the same way.  I would consider this an architectural
>>issue, so maybe it's time this issue should be sent to the TAG.  (Two
>>of the three authors of RFC 2396 are on the TAG.)
>
>Hi Paul,
>
>It may be that this needs to go the tag, but I'd like to make sure we do our best to clarify the issue first.  I hope Jeremy will forgive me butting in.
>
>I'll try to keep this short, but it may be a little long.
>
>First: the problem RDF is trying to solve.  The current RDF specs have encouraged the use of the following idiom:
>
>  <rdf:Description rdf:about="#foo">
>    ...
>
>The value of the rdf:about attribute is turned into an absolute URI reference by concatenating the '#foo' with the URI of the containing document.
>
>This causes problems.  Folks copy the file from the web to their hard drive so they can work on it in a plane, and the uri changes to something like file:c:\temp\....rdf and this is really useless for rdf users.  Or folks wish to include RDF in say a message protocol where  there is no base uri of the document.
>This is the cause of one of, if not the, most frequent newbie problem with DAML that we see on jena-dev.
>
>So we are looking for a way to retain this convenient syntax, but have the uri's produced not change when the file is copied or mirrored.
>
>To appreciate what is happening here, we need to look at a semi-fictional RDF processing pipeline:
>
>
>input xml document -> xml parser -> rfc2396 processor -> rdf parser -> rdf graph
>
>We start with an xml document and end up with a datastructure.  The datastructure is not a DOM; its not a representation of an xml document.  It is as far as xml is concerned, an application data structure.
>
>For each value of an rdf:about attribute, the rfc2396 processor outputs either an absolute URI or a same document reference.  The absolute URI is processed according to RFC2396.  Same document references are recognised according to RFC 2396.
>
>All is in conformance with rfc 2396 at this point.
>
>Now the RDF parser comes in to play and it is required to transform the value of each rdf:about attribute into an absolute uri reference.  If the RFC 2396 processor has produced an absolute uri reference, it need do nothing.  If however, it is a same document reference, then, just as a browser will handle same document references specially, so does RDF.  It transforms the same document reference into an absolute URI according to an algorithm defined by the RDF specs.  The mimetype of an rdf document will be text/xml+rdf.  As far as xml base and rfc 2396 are concerned, this is application code over which they have no say.
>
>What I have tried to do here is to position RDF as an application built on top of XML and to suggest that XML should not be allowed to express constraints on how applications process it.
>
>There is a deal of sophistry in this argument :( but RFC 2396 doesn't really meet our needs.  Are there any plans to update/refine it in the near future?
>
>Brian

Received on Monday, 15 April 2002 14:13:52 UTC