Re: Proposed comment about CURIEs

Dear Bijan and Bijan,

Thanks for doing this:-) But, unfortunately I have concerns with several
parts of the proposed response, because I am not sure whether they
reflect any kind of WG concensus and (as Bijan #2 rightly pointed out)
the style for an official WG response may not be kosher either. I would
propose to greatly reduce the text to the bare minimum on why the WG has
decided to go its own way (which has been decided and accepted by the
WG) and leave all other issues aside. Those have not been discussed by
the group at full depth, ie, they do not necessarily reflect the opinion
of the group (and I do not think we should use the WG's time to discuss
them because they may be not really relevant for the WG).

So, using Ian's guiding principle on 'less is more', I reduced the size
of your proposed response to the following, which I would propose to be
the basis of our official WG answer:

[[[
www-html-editor@w3.org

Subject: Various issues with using CURIEs in OWL

The OWL Working Group had intended to delegate our URI abbreviation
mechanisms both for in-spec and in-concrete-syntax use. OWL has a number
of different concrete serializations (including 2 XML based and 2
non-XML based), all of which use some form of URI abbreviation mechanism.

Unfortunately, the WG has found that the current CURIE spec does not
meet our needs:

1) For non-XML host languages: The CURIE spec provides no mechanism
(although it provides permission) for excluding characters from the
syntax of the local part of CURIEs. This means that in host languages
which use symbols like ")" or "[" as part of their syntax, we run into
parsing ambiguities. Note that safe CURIES do not solve this problem as
the safe CURIE delimiters are common host language delimiters.

Ideally, there would be a "mimimalistic" CURIE profile, for example
something like SPARQL's abbreviation mechanism. Even QNames would be
fine (though we'd recommend the spec point out that to cover all URIs
there should be a non-abbreviated form).

This also affects XML Host languages for OWL. Although the parsing
issues are not relevant for XML, consistency requires that the XML
serialization would follow the same rules on the set of characters used
than the non-XML host languages.

2) For XML host languages: The requirement to support the XML namespace
based prefix declaration mechanism, even when an alternative mechanism
is supplied, was not appropriate for the group. Many in the XML world
are hostile to the namespace based overload, and it is not up to the OWL
Working group to take side on this issue.
]]]

I actually wonder whether #2 is necessary at all. Consistency with the
M'ter and FS is important in my view, so even if the namespace mechanism
would not be controversial I am not sure we would adopt CURIE-s for
OWL/XML anyway. Ie, I am tempted to remove that paragraph altogether, too.

We could also add one more argument, actually (which we should have
realized much earlier), namely that a consistency with other SW
serializations like Turtle and SPARQL is also an important point for us,
ie, aligning to SPARQL makes much more sense for a SW specification. But
I am not sure it is worth adding this.

Sorry:-)

Ivan



Bijan Parsia wrote:
> Bijan!
> 
> Thanks for doing this. I'm pretty fine with most of the text, but I have
> a concern with one part below.
> 
> On 3 Apr 2009, at 16:57, Bijan Parsia wrote:
> [snip]
>> I (Bijan) would like to add that for a long time I, and everyone I was
>> talking with, thought that you *couldn't* further restrict the syntax
>> of CURIEs. The liberalizing sentence occurs *10* paragraphs after the
>> CURIE grammar! Those 10 paragraphs are a mismash of things about the
>> *syntax* of CURIEs and things about the *host language*. We strongly
>> recommend rewriting that section with (at least) two headings "further
>> syntactic stuff" and "host language issues"
>>
>> Actually, just move the stuff on host language issues into, you know,
>> the section on "Incorporating CURIEs into Host Languages", make that
>> section informative, and kill all the examples (or move them to,
>> y'know, an examples section). While you're at it, merge "usage" into
>> examples as well.
>>
>> C'mon! This is supposed to be a SPECIFICATION and most of it is random
>> blathering and examples. The conformance section is a JOKE and the
>> normative section, for all its brevity, is a disaster to read. Write
>> the spec. Make it tight. And give us a clear pointer to the part we're
>> supposed to USE, please.
> [snip]
> 
> While I understand and sympathize with your frustration, I don't think
> it's productive or helpful to include this in the official WG response.
> Instead, we might take the specific editorial recommendations and
> sanitize their expression. E.g.,
> 
> """EDITORIAL NOTE: Many of us found the organization of the spec, and
> especially of the normative parts, very confusing. We 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"."""
> 
> Again, thanks for doing this
> 
> Cheers,
> The Other Bijan.
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf