W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2009

Re: ACTION-267 DONE

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Fri, 23 Jan 2009 09:34:26 +0000
Cc: W3C OWL Working Group <public-owl-wg@w3.org>
Message-Id: <D7577892-3F8D-42E6-B8F8-887492CD5237@cs.manchester.ac.uk>
To: Ivan Herman <ivan@w3.org>

On 23 Jan 2009, at 09:09, Ivan Herman wrote:

> Bijan Parsia wrote:
>> On 22 Jan 2009, at 09:52, Ivan Herman wrote:
>>
> [strip]
[snip]
>> Here's another possibility: Leave it to be tied to the latest Unicode
>> but point out that serializations and parsers (and apis) would need  
>> to
>> be updated. That way, we do not discriminate against people who  
>> need the
>> new characters. In the conformance document, we could discuss this  
>> and
>> even suggest (require?) that *implementations* indicate which  
>> version of
>> Unicode they support. This would add some implicit pressure to keep  
>> up
>> to date wrt Unicode.
>
> Yes, that may be a way forward indeed. More exactly: the text should
> spell out what users might face with serializations that have not been
> updated to Unicode 5 or later.

Note that this doesn't just apply to serializations...it handles the  
inconsistency with new versions problem. An ontology can be consistent  
with regard to Unicode 5 and inconsistent with regard to Unicode 6.

[snip]
>> Indeed, I rather suspect that RDF should update, esp. given the  
>> (widely
>> loathed) XML revision 5. Certainly the *model* should track Unicode
>> latest....perhaps this could be considered an errata? Given the right
>> conformance description, such a change would have no impact on
>> implementations.
>
> Given that this came up, I think recording an errata for RDF, stemming
> from this group, might be a good idea indeed!

Ok. What do we do?

> (To be fair to the RDF group of the time: this issues were way murkier
> at the time. The I18N guys tried to clarify things a bit but, for
> example, the character model document came out a year after RDF...)

Yep. It was very tricky at the time. It's tricky now!

>> (Actually, there's an interesting question about RDF now. RDF/XML  
>> refers
>> normative to XML revision 2! Wacky. That means that RDF parsers  
>> should
>> reject XML documents that use revision 3-5 features? Are there any  
>> 3-4
>> features which make a difference?)
>
> Sigh:-( I am not sure...

I'm not deep enough into XML parsing to tell (yet) :)

>> BTW, I'm in favor of making rdf:text/xsd:string whatever have finite
>> alphabets. Discussions with Birte about her datatype implementation  
>> seem
>> strongly in favor (mostly in the reuse of existing automata  
>> libraries).
>> There's a number of ways to handle this including parameterizing
>> text/string (i.e., with unicode version).
>
> I hear Boris' argument on ontologies becoming inconsistent over time.
> Having said that: I would be curious to see how frequent this (in my
> view, hightly theoretical!) issue is. Defining the number of  
> characters
> to be infinite is a little bit unnatural indeed...
>
> A slight procedural issue, though (sorry Bijan! Breaking our rule
> here:-(: I think we should register a separate LC comment on the
> infinity of characters if we want to. This does not have anything to  
> do
> with Martin's comment...

Consider this my "in group" LC comment to this effect. If we have to  
touch datatypes again, if we can figure out a way to get rid of the  
infinite alphabet that would be very valuable.

My thought is that we make the "implicit" parameter be "the latest  
version of unicode", since that's what i think most people mean. If  
you are in the situation of defining a datatype that would be  
sensitive to a change in the base alphabet, you should either accept  
that possibility or use rif:text?UnicodeVersoin=3.

Cheers,
Bijan.
Received on Friday, 23 January 2009 09:35:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 January 2009 09:35:04 GMT