W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2008

Re: review of rdf:text, dated 2008-11-04

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Thu, 06 Nov 2008 20:01:02 +0100
Message-ID: <49133EEE.1090504@inf.unibz.it>
To: Bijan Parsia <bparsia@cs.man.ac.uk>
CC: RIF WG <public-rif-wg@w3.org>


Bijan Parsia wrote:
> 
> On 6 Nov 2008, at 13:43, Jos de Bruijn wrote:
> [snip]
>>> I think you are not quite grasping the issue here. (I do prefer finite
>>> alphabets myself, fwiw.) The point is how to design the type so that it
>>> is extensible to additional characters that will definitely be added (by
>>> unicode). Note that problems along these lines have already occurred in
>>> XML land. I don't think we can *merely* punt on this.
>>
>> What problems are there in XML land?
> 
> http://norman.walsh.name/2004/09/30/xml11
> 
>> In any case, like XML, this definition relies on ISO/IEC 10646, which
>> has provisions for extensions. It seems to me that this is the
>> appropriate way to deal with extensibility; it's not necessary to define
>> our own mechanism.
> 
> We're not defining our own mechanism per se, we're trying to accommodate
> the fact of extensions.
> 
>> In general, I think that this datatype should be based on the XML schema
>> string datatype, and if there are problems with extensibility, they
>> should be solved in XML schema.
> 
> It *is* based on XML schema strings.

No. The string parts of the lexical space and value space are different.

> 
>>> (And the problem is that future changes will change the meaning of some
>>> ontologies. I presume that this will be true for some RIF rulesets if
>>> you have the appropriate facets and builtins.)
>>
>> We don't have such problems in RIF, because we don't allow built-ins in
>> rule head.
> 
> I fail to see how that matters. You'll get different answers to builtins
> so you'll have different rules firing merely depending on the admissible
> characters.

You're right, I forgot about this point. I was focusing too much about
the example in the document.
But, well, there will be future changes in several data types, so I
guess we'll just have to live with that.

Best, Jos

> 
>> Further, if future changes in data types potentially pose a problem to a
>> particular language, the specification of that language should deal with
>> this problem. I suspect that OWL 2 does something like that for the
>> string data type.
> 
> This is how it's done :)
> 
> You should talk with Boris more than me. I'd personally prefer a finite
> alphabet and bite the bullet on extensions (I think...). But you don't
> seem to be acknowledging the issue.
> 
> Cheers,
> Bijan.
> 
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster


Received on Thursday, 6 November 2008 19:28:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:58 GMT