Re: Generic processing of Fragment IDs in RFC 3023bis

On Thu, Oct 7, 2010 at 3:44 AM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:
> On 2010/10/06 21:54, Jonathan Rees wrote:
>
>> Suppose we have an application that can display XML elements, or do
>> some other processing on them. It is given a URI (or more precisely an
>> absolute URI reference with a fragment id). It has a choice of either
>> of two APIs or libraries to use to determine an element designated or
>> "identified" by the URI. Library 1 selects elements according to XML
>> generic fragid processing, while library 2 is an RDF processor that is
>> capable of inferring, based on available axioms, that the URI
>> "identifies" an XML element and, in fact, some particular element
>> whose properties (its attributes and so on) are known.
>>
>> Depending on which URI-derefencing library the application chooses to
>> use, the application will get either of two different elements for the
>> same URI - even if none of the information involved in the
>> determinations is stale.
>
> Given that XML fragment identifiers are pretty well established these days,
> it would in my opinion be a rather strange failure on the RDF side to create
> an RDF-based vocabulary to identify XML elements (and other syntactic
> constructs) where the same fragment id identifies different XML elements.
>
>> Without considering the question of which library the application
>> "should" use, it appears that you are saying three things: first, that
>> this is a perfectly natural state of affairs, so it has to be accepted
>> because it's the way the world works;
>
> I'd say that the RDF side should be fixed.
>
>> second, that the cat is out of
>> the bag and we couldn't change things even if we wanted to;
>
> Is there already such an RDF library?

My scenario was constructed to exaggerate the problem. In the example
we have XML resolution giving one element, and RDF resolution giving
another. This is purely hypothetical, but is consistent with RDF's
design (inference over *arbitrary* domains - including the domain of
XML elements) and with the way that RDF is used (# URIs to refer to an
arbitrary thing as described by the RDF - like maybe an XML element).
A more realistic situation is where XML resolution gives an element
and RDF "resolution" of the same URI gives something that is not an
element - say, a data structure, a document, a type, a company, etc. I
don't have an RDF/XML document in hand that exhibits this problem, but
I note that it will arise almost any time rdf:ID is used (e.g. to do
RDF reflection).

(My factual question of whether generic XML processors must treat
rdf:ID the same as xml:id hasn't been answered, by the way - so we're
not sure there's a problem at all!)

You could say there's no ambiguity if XML resolution gives an element
and RDF "resolution" (reference) gives something that cannot be
confused with an element (such as an rdfs:Statement perhaps?). Note
that the same argument has been brought forth before: as observers of
the www-tag list may have realized, the question we're discussing is
just another manifestation of the httpRange-14 issue. So you can
dredge up all the old person-versus-document arguments pro and con
that were raised for non-# URIs, and have a field day. If you were
someone who insisted that HTTP reference and RDF reference ought to
coincide for non-# URIs, then you ought to insist that XML reference
and RDF reference should coincide for # URIs.

(Appearances to the contrary, I'm trying to stay neutral.)

>> and third,
>> that the practice of having multiple interpretations is valuable and
>> we shouldn't change it even if we could.
>
> For many reasons, it may be a bad idea to change things that work. I don't
> know about Roy, but I sure wouldn't go as far as 'valuable'.
>
>> Many people would consider coherent reference across protocols or
>> interpretation contexts a meaningless and misguided goal, while others
>> consider it the heart of web architecture.
>
> My position would be that it may not always be possible, but that it is
> certainly a meaningful and worthwhile goal.

Sounds reasonable to me. Nudging RDF/XML in the direction of
consistency with XML (or as Roy suggests abolishing RDF/XML
altogether) seems like good engineering, even if we can't go back and
fix deployed RDF/XML content.

I think the particular situation we're discussing is not so
consequential. It is just a pawn in the old debate over "URI meaning"
best practice.

Best
Jonathan

[message composed before receipt of Graham Klyne's 7:52am EDT message]

> Regards,    Martin.
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Thursday, 7 October 2010 12:29:31 UTC