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

Re: a few comments about DTB

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Mon, 23 Jun 2008 14:01:11 +0200
Message-ID: <485F9087.7020508@inf.unibz.it>
To: Axel Polleres <axel.polleres@deri.org>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

PS the following text in section 4.1 does not make sense:
"naming convention we use the capitalized non-prefix XML local name part 
denoting the data type"
for example, rif:text and rdf:XMLLiteral do not have a local part, since 
they are not XML names; they are absolute IRIs.

I think that when defining datatypes in section 2.2 you should define 
the short names: every datatype has a short name, starting with a 
capital letter.  For the XML schema datatypes, this short name is the 
capitalized version of the name (notice it in XML schema, datatype names 
are not IRIs, and do not have a namespace).  For rif:text it is Text and 
for rdf:XMLLiteral it is XMLLiteral.

Finally, you can define the guard predicates for all datatypes in 
section 4.1, also for the user-defined datatypes.  I guess you already 
do so, since the definition of the schema and the semantics are already 
I actually do not really understand why you duplicate the schema 
definitions in the subsections of 4.1.

Best, Jos

Jos de Bruijn wrote:
>>>>> how about that the beginning of section 4.1:
>>>>> "For each datatype a guard function is defined."
>>>> Does that mean we impose guards and negative guards for *ALL* 
>>>> datatypes?
>>> I'm not sure what you mean with "impose".  We simply define the 
>>> functions.
>> I mean: whenever oned defines a new datatype, you mean that 
>> implementeing guards and negative guards have to be implemented as well?
>> I reformulated this slightly now.
> Requiring implementing guards for datatypes is really a conformance 
> issue, and the conformance statement currently in BLD does not require 
> guards to be implemented for supported every datatype, and I think that 
> is fine.
> I do think that guards need to be defined for every datatype. If one 
> wants to use these guards, one can do so.  But one can only share the 
> rule sets that use of such guards with consumers that support the 
> guards, which is fine, I think.
> Best, Jos
>>>>>>> - section 4.3, casting:
>>>>>>> The casting functions are under-defined:  1 It is unclear for 
>>>>>>> which data
>>>>>>> types these functions are defined.
>>>>>> I improved this.
>>>>> I noticed that in section 4.3 there still a mention of "RIF 
>>>>> supported datatype".
>>>> see above.
>>> So, get rid of it! Deleting words is easy.
>> reformulated.
>>>>>>> 2 the reference to the table in section 17.1 seems to be 
>>>>>>> incorrect.  The
>>>>>>> table does not specify any conversions.  It actually specifies which
>>>>>>> cast functions are defined, not how they are defined.  You can 
>>>>>>> probably
>>>>>>> use the table for defining which cast functions exist.
>>>>>>> Then, the table only speaks about XML schema datatypes, which seems
>>>>>>> insufficient for our purposes.
>>>>>> I am not sure how to address this comment. I think as for the 
>>>>>> cases not covered by the table, the restructureing which i did now 
>>>>>> fixes this.
>>>>> Yes.
>>>>>> If you say that the conversion itself is not covered... well, all 
>>>>>> these casts are explained in detail in the subsections of 17.1. 
>>>>>> so, I could reword to "as shown in the table ... and defined in 
>>>>>> the subsections ...
>>>>>> but I definitly don't want to duplicate anything here.
>>>>> you do not need to redefine things, but you do need to include 
>>>>> specific references. Plus, you need to say how the RIF casting 
>>>>> functions are obtained from the xquery casting functions.  For 
>>>>> example, the sections talk about raising errors, which is not 
>>>>> supported in RIF.  Nonetheless, you need to say what happens in the 
>>>>> RIF casting function if such an error is raised.
>>>>> So, for each casting function, you need to carefully check what the 
>>>>> relationship is between the intended RIF casting function and the 
>>>>> x-query function and make sure your definition is a complete 
>>>>> definition of the function.
>>>> I need to rethink this... not dure whether I can address it before 
>>>> my vacation (going to be from tomorrow until end of next week)... 
>>>> maybe this can wait for the second WD?
>>> I guess it can wait.  But please include editor's notes saying that 
>>> the functions are to be defined.
>> done.
>>>>>>> 3 you can probably use the text in section 17.1 to specify (part of)
>>>>>>> some of the cast functions.  However, you do need to take care of 
>>>>>>> the
>>>>>>> non-XML schema casting and the handling of errors.
>>>>>> precicely, that is why I think a reference to section 17.1 and the 
>>>>>> improvements I did now are sufficient (at least for first public WD)
>>>>> The improvements are not sufficient, as I argued above.  If you 
>>>>> want to go ahead and publish these incomplete definitions in the 
>>>>> first public working draft, you should at least include an editor's 
>>>>> note saying that these functions will be specified in more detail 
>>>>> in a future version.
>>>> Did so.
>>>>>>> 4 rif:XMLLiteral -> rdf:XMLLiteral (in several places in the 
>>>>>>> document)
>>>>>> done
>>>>>>> 5 conversion between IRIs and strings cannot be defined as a 
>>>>>>> function.
>>>>>>> It could be defined as a predicates.  Please recall the 
>>>>>>> discussion and
>>>>>>> the revised definition in [1].
>>>>>> will do that next... this is how far I got today. attacking your 
>>>>>> other mails hopefully over the week.
>>>>>>> - I wonder what the justification is for just retaining the 
>>>>>>> language in
>>>>>>> the cast from text to string
>>>>>> because you want to get the "pure" string out of it, disregarding 
>>>>>> the lang tag... the lang tag can be extracted with func:lang.
>>>>> So why not an extraction function for the string part? 
>>>> matter of taste...
>>>>> Usually, when casting from one type to another, you don't want to 
>>>>> lose information. For example, you don't want to cast a negative 
>>>>> integer to a nonnegative integer by simply removing the negation, 
>>>>> because you lose information.
>>>> ... I find the former more intuitive, since I do not consider the 
>>>> lang tag part of the string. We may vote over it, I think there are 
>>>> arguments for both views.
>>> Please include an editor's note in the draft saying that the function 
>>> is still under discussion.
>> done.
>>>>>>> - section 4.7: I don't really like the name of the function 
>>>>>>> ("lang");
>>>>>> I do. This is also used in SPARQL.
>>>>> I think built-in functions should all use the same naming convention.
>>>>> Other opinions anyone ?
>>>> If not, I would rather keep it.
>>> Please include an editor's note in the draft saying that the name is 
>>> still under discussion.
>> done.
>> Axel
>>> best, Jos
>>>> Also see that I now chenged the subheadings in the document to 
>>>> better reflect the origin of our built-ins.
>>>> Thanks for the continuous comments! Helps a lot!
>>>> Axel
>>>>> Best, Jos
>>>>>>> this sounds more like the name of an attribute.  I would prefer 
>>>>>>> using
>>>>>>> the Xquery convention: lang-from-text
>>>>>>> Best, Jos
>>>>>>> [1] 
>>>>>>> http://lists.w3.org/Archives/Public/public-rif-wg/2008Mar/0023.html
>>>>>>> -- 
>>>>>>> Jos de Bruijn            debruijn@inf.unibz.it
>>>>>>> +390471016224         http://www.debruijn.net/
>>>>>>> ----------------------------------------------
>>>>>>> An expert is a person who has made all the
>>>>>>> mistakes that can be made in a very narrow
>>>>>>> field.
>>>>>>>    - Niels Bohr

Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
Public speaking is the art of diluting a two-
minute idea with a two-hour vocabulary.
   - Evan Esar
Received on Monday, 23 June 2008 12:00:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:51 UTC