Re: Proposed comment about CURIEs

On 4 Apr 2009, at 10:35, Ivan Herman wrote:

> 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

Well, I put them forth to determine that. I tried to list all the  
technical problems that were raised leading to our decision to not use  
CURIEs. That we didn't determine consensus on each is a bit moot.

> 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.

All the issues I raised contributed, IMHO.

> 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).

I'm happy to pull things that might be contentious, but I'm reluctant  
to pull things that "might" be contentious. The simple principle would  
be that if someone, now, objects to including it in this message we  
either don't include it or mention that that point doesn't have  
consensus.

> 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.

Yes.

> 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.

It was an independent problem. *If* we could have used CURIEs in  
Manchester syntax, I would have objected to only using xmlns, Sandro  
might have objected to using a redundant method; actually I would have  
objected to having redundant xmlns.

This was at least one contributing factor to ditching CURIEs.

> 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.

I don't see that as a distinct argument. Presumable, the intention was  
that everyone converge on CURIEs.

I'm not sure why you think the last two point are controversial. If we  
had a processing model, we wouldn't have to invent one. If we had a  
standard xml syntax, we wouldn't have had to invent one. We almost  
missed *both* of these. That is, until quite recently, we didn't have  
CURIEs *at all* in XML syntax. Similarly, until quite recently,  
afaict, we had no processing model in *any* of our serializations.

So, I'd like to retain all points if you're just rejecting them on a  
"let's be conservative" basis. I made the proposal to reject CURIEs  
and these points were all mentioned, I'm pretty sure.

Cheers,
Bijan.

Received on Saturday, 4 April 2009 09:52:27 UTC