W3C home > Mailing lists > Public > www-html-editor@w3.org > April to June 2009

Re: Various issues with using CURIEs in OWL

From: Shane McCarron <shane@aptest.com>
Date: Fri, 10 Apr 2009 08:26:14 -0500
Message-ID: <49DF48F6.8030005@aptest.com>
To: Bijan Parsia <bparsia@cs.manchester.ac.uk>
CC: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>, www-html-editor@w3.org, W3C OWL Chairs <team-owl-chairs@w3.org>

Bijan Parsia wrote:
>>> EDITORIAL NOTE: Many of us found the organization of the spec, and 
>>> especially of the normative parts, very confusing. See:
>>> <http://www.w3.org/mid/943ED7DE-FBC9-4110-B17B-AF9F8043A0A1@cs.man.ac.uk> 
>>> I suggest that "Usage" and "Examples" be consolidated, and that 
>>> there are two normative sections, "Syntax" and "Incorporating CURIEs 
>>> into Host Languages" which contain the respective constraints. The 
>>> second section could usefully be broken down into "XML host 
>>> languages" and "Non-XML host languages".
>> Thanks for this.  We are already done with CR more or less, but I 
>> will see what I can do.
> I don't see how you can get out of CR to PR, looking at your 
> implementation report. At this stage, I'm now asking Sean, my AC rep, 
> to oppose such a transition.
Well - the implementation report has not been updated recently.  I 
didn't mean that we were transitioning tomorrow.  But there are a number 
of implementations and uses for CURIEs now.  I believe we have satisfied 
the CR exit criteria, or will have once we are done gathering the 
> Speaking as a spec implementor who sincerely tried to use the CURIE 
> spec, I think there are problem that merit serious changes to the 
> design of the language. This means another LC, if I'm not mistaken.
Perhaps - not really up to me. 
> Well...if that means that we all reinvent ours, then I don't think 
> it's a good idea. For me, this means that the CURIE spec is not a rec 
> track sensible document, but would be better as a note.

CURIEs are in use in many rec track documents currently, as well as in 
the RDFa Recommendation.  The reason CURIEs are separated out is so that 
all of these documents can have a consistent definition.  I am 
interpreting your core objection here that there are not defined 
profiles that would make it easier to have such a consistent definition. 
As I said, I am sure the working group will get back to you formally.

>>  The concept of a CURIE, that is an abbreviation that maps to an IRI, 
>> is general.  The expression of that concept in a host language is 
>> necessarily going to be related to that host language.  For example, 
>> were you to use CURIEs in HTML you would not want to use some "xml" 
>> mechanism to map a prefix.
> Sure, but, uhm, HTML is not an XML host language. And I'm confused as 
> to why we're talking syntax rather than processing.
I only mentioned it because you suggested defining a prefixing mechanism 
in the XML namespace.  I was pointing out that HTML wouldn't be able to 
use such a mechanism.  Sorry if I was unclear.  Moreover, SPARQL would 
not be able to use a similar mechanism.  The ability to have the host 
language define the syntactical mechanism is essential.  I think I agree 
it would be best if the resulting CURIEs were all similar - but as you 
point out that is unlikely since there are different constraints that 
host languages will want to put on the reference portion.

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 10 April 2009 13:27:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:08:56 UTC