Re: [Admin] Agenda for RIF telecon 17 April

We talked about the issue in the CG today.  The general sense was that 
going with IRIs is the W3C way to go, however no one present would 
admit to understanding what the impact is.

A few notes:

Dave Reynolds wrote:
> Is there some specific objection to specifying IRIs?

Nothing technical at all.  The objection was not to IRIs per se, but 
to making a decision without understanding the consequences.  I think 
the only thing we're talking about wrt consequences here are related 
to perception and adoption (of RIF).  If we insist on IRIs, and no one 
in our perceived customer set actually uses them, we may put people off.

> My reasoning in favour of them are:
> 
> 1. They are a superset of URIs and specifying the superset seems like 
> the safe default course. If someone especially wanted a dialect with 
> syntactic restriction to URIs then they could add that restriction in 
> the dialect.

IRIs are not a superset of URIs - this would imply that all URIs are 
IRIs, which is simply not the case.  Every URI can be encoded as an 
IRI through a well-specified mapping, but URIs are not themselves IRIs.

> 2. For any translator working with an ascii only language they can use 
> the algorithm in rfc3987 section 3.1 to map to a URI form internally.
 >
> 3. This is more compatible with the existing semantic web stack. The RDF 
> Spec used the term "RDF URI Reference" because it pre-dated RFC3987 but 
> the definition is basically an IRI [*]. SPARQL specifies IRIs (and is 
> where I lifted bits of the draft text from) and they have had no adverse 
> feedback on this choice, it was not seen as in any way contentious.

On the contrary!  It is an IMMENSE source of confusion!  As we are 
seeing here.  Now that we have a IETF RFC for IRIs, I do think the 
confusion will start to dwindle, but we are not there yet.

> 4. This is the I18N friendly choice. Apart from any general arguments as 
> to why I18N might be relevant, the W3C process requires that our spec be 
> reviewed by the I18N WG and I for one wouldn't want to try to explain to 
> them why we deliberately avoided IRIs unless we had a good reason.

We have not proposed avoiding IRIs, we are considering whether the 
spec should "require" them, in a sense, or make them an alternative. 
I see the choices as having "URI or IRI" in the spec vs. just "IRI".

-Chris



> 
> Dave
> 
> [*] The relevant part of the RDF spec [b] followed the draft IRI spec 
> that was available at the time. After RDF was published the IRI draft 
> changed slightly at the last stage of the process. As far as I am aware 
> the only relevant change is that IRIs as per RFC3987 do not permit 
> spaces but the RDF URI Reference spec does. However, the RDF spec [b] 
> included some future proofing by specifically allowing processors to 
> issue additional warnings of any RDF URI Reference which fails to meet a 
> successor of the IRI Draft, which licenses implementations like Jena 
> which try to conform to RFC3987.
> 
> [a] http://lists.w3.org/Archives/Public/public-rif-wg/2007Mar/0133.html
> [b] 
> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-URIref
> 

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Friday, 13 April 2007 19:35:37 UTC