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?

This has to do with a previous discussion several weeks ago where it was
agreed that relative URIs will not be part of the logic, but simply treated
as syntactic sugar, a macro. This has nothing to do with the rest of the
discussion about the RFCs etc. I simply said that this stuff hasn't been
defined yet in the document and mentioning it at this point makes no sense.


	--michael  

> 
> 
> > 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:56:49 UTC