Re: IRI text, addendum

Michael Kifer wrote:
>>Michael Kifer wrote:
>>
>>>>We started to discuss this on the call today but shelved it while I 
>>>>found the text and never got back to it ...
>>>>
>>>>My original proposed text [*] relating to issue 30 actually had two 
>>>>paragraphs. We've covered the first one. The second one mentioned the 
>>>>resolution of relative IRIs into absolute IRIs.
>>>>
>>>>Is there any reason to not also include this second paragraph?
>>>>
>>>>Checking the SPARQL spec, which is where the substance of this text came 
>>>>from, I see one more sentence would be useful, so the revised proposed 
>>>>second paragraph is:
>>>>
>>>>[[[
>>>>In the concrete XML and human readable syntax relative IRI references
>>>>are permitted in which case they will be resolved relative to a base IRI
>>>>as per Uniform Resource Identifier (URI): Generic Syntax [RFC3986] using
>>>>only the basic algorithm in Section 5.2. Neither Syntax-Based
>>>>Normalization nor Scheme-Based Normalization (described in sections
>>>>6.2.2 and 6.2.3 of RFC3986) are performed. Characters additionally 
>>>>allowed in IRI references are treated in the same way that unreserved 
>>>>characters are treated in URI references, per section 6.5 of 
>>>>Internationalized Resource Identifiers (IRIs) [RFC3987].
>>>>]]]
>>>>
>>>>This does two things. Points out that you can use relative references in 
>>>>source documents (they become absolute IRIs in the abstract syntax). 
>>>
>>>
>>>This reference to relative URIs is out of place here. When and if we
>>>introduce syntax for relative URIs and define the exact macro processing
>>>for them then we will talk about it.
>>>
>>>
>>>
>>>>Spells out that there is no normalization step, which implies that 
>>>>equivalence is the simple string comparison that we've discussed in email.
>>>
>>>
>>>This is already captured in a more precise way when we said that there are
>>>no equalities implied for the sort of the uris.
>>>
>>>
>>>
>>>
>>>>If we would like to capture that sentiment but wanted text that 
>>>>separated those two issues more clearly I could draft that but the above 
>>>>has the advantage that if it's good enough for SPARQL then it's good 
>>>>enough for us.
>>>
>>>
>>>I don't think that what is good for SPARQL is good for us.
>>>The SPARQL document is full of rather vague pieces, which I hope we will
>>>avoid.
>>
>>Some of which I also mentioned in the review sugggestion... if you have 
>>more, please let me know.
> 
> 
> 
> If I had time I would have done that. This is true not only of the SPARQL
> document, by the way. Many W3C documents have this tendency of saying simple
> things in a convoluted way (XML Schema, WSDL, to name a few).
> 
> 
> 
>>>It is also replete with external references, which makes it hard to
>>>understand without lengthy detours. The paragraph you quoted above is a
>>>good example of this sort of a bad style.
>>
>>I wouldn't thought have considered that one as problematic, though.
>>It might be said simpler though, as you suggest...
> 
> Not problematic? Really? If Dave and Jeremy didn't explain previously that
> this simply means textual equality, it would have taken me 30 mins or more
> to understand just this one paragraph.

:-) As I said, I agree it could all be said simpler, probably.

>>>Why not simply say that two URIs are distinct if they are not identical?
>>>Instead, the paragraph invokes the normalization stuff,
>>
>>... but well, the only normalization I see here is resolution of 
>>relative IRIs, right? As you mentioned above, you don't seem to disagree 
>>that we can proceed the same way:
>>
>> > When and if we introduce syntax for relative URIs and define
>> > the exact macro processing for them then we will talk about it.
>>
>>I don't see how/why the preprocessing in RFC3986, sec 5.2 would
>>contradict this or why it wouldn't be a valid candidate?
> 
> 
> I have no idea what are you talking about. 

The "nomalization stuff" suggested in SPARQL is the preprocessing by the 
algorithm in RFC3986, sec 5.2, ie. the preprocessing of relative IRIs. 
You were mentioning that we will have to decide "if we introduce syntax 
for relative URIs and define the exact macro processing for them" which 
is defined exactly there. So, I was asking you why this is not good enough?


> The relative URI business has
> nothing to do with the RFC business. 

? URIs are defined in an RFC, so, I don't understand what you want to 
say with this. Can you explain?

> It would be just out of place and out
> of nowhere if we were to include it in RIF as suggested.


best,
axel


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Thursday, 19 April 2007 10:26:04 UTC