Re: a few comments about DTB

>>>> Here are a few things I noticed in the DTB document during the meeting:
>>>>
>>>> - you use DATATYPE sometimes as the IRI of a datatype and sometimes 
>>>> as a
>>>> non-IRI name of a datatype.  It is unclear what the relationship is
>>>> between these two names, especially since according to section 2.2 the
>>>> names of the data types are IRIs.  In addition, the names are not 
>>>> always
>>>> what one would expect.  For example, I would expect the short name of
>>>> the xs:string datatype to be "string".  However, in section 4.1 and 4.2
>>>> it seems to be "String".
>>>> I guess it probably makes sense to use some kind of short names for the
>>>> datatypes in the names of certain predicates, but the relationship 
>>>> needs
>>>> to be defined.
>>>
>>> I added respecting paragraphs in 4.1 and 4.2 explaining the naming 
>>> convention.
>>>
>>> "As a naming convention we use the non-prefix NCNAME part denoting 
>>> the data type in CamelCase, for instance we use pred:isString for the 
>>> guard predicate for xsd:string, or pred:isText for the guard 
>>> predicate for rif:text. Other RIF dialects involving new datatypes 
>>> not mentioned in the present document MAY follow this convention 
>>> where applicable without creating ambiguities with predicate names 
>>> defined in the present document."
>>
>> I'm not sure this is sufficient; specifically, you do not define what 
>> the labels are for any of the datatypes, you only include some 
>> examples.  I think we need to define the concept of a "label" for 
>> datatypes, and the labels for the XML schema datatypes should be 
>> mentioned explicitly.
>> Then, I am not convinced about the naming convention.  Why not just 
>> capitalize the first character? the camel case convention seems overly 
>> invasive.
> 
> what about e.g. "is-string"? better?

isString is fine, but you should not require capitalization further down 
the line.  For example, for a datatype "mystring", the guard predicate 
should be called "isMystring" (capitalization of first letter of label), 
rather than "isMyString" (camel case).

> 
>> In addition, I don't think the term "dialect" should be used, because 
>> it is nowhere really defined.  I would suggest changing the last 
>> sentence to:
>> "Labels used for datatypes not mentioned in
>> the present document MAY follow this convention where applicable without
>> creating ambiguities with predicate names defined in the present 
>> document."
> 
> fair enough. done.
> 
> 
>>> What I realized is whether we should in general forbid external 
>>> enitities to define external schemata for rif:..., pred: or func: 
>>> prefixed builtins. This is not aa issue for DTB though, but rather 
>>> for extensibility.
>>
>> I don't think it should be forbidden.
> 
> The rationale for this remark was: I am not sure whether we want the 
> pred: and func: namespaces to be hijakced by third parties. thus, it 
> could make sens to add a respective remark that these are supposed to be 
> the standard namespaces for RIF  defined predicates and functions. This 
> should be a guideline rather... maybe the word "forbid" was too string, 
> I rather meant "discourage".
> 
>>>> - section 4.1, first sentence: as discussed in the meeting, it is
>>>> unclear what is meant with "RIF supporting a datatype".  As agreed in
>>>> the meeting, a dialect may require implementations to support a 
>>>> specific
>>>> datatype.  
>>
>> I think you missed this comment.  The unclear phrase is still in the 
>> section.
> 
> Still lacking a better proposal... may be I missed it.

Just get rid of this phrase.

> 
>>>> The DTB document then only needs to specify that whenever a
>>>> datatype is supported, also the corresponding (which is a concept also
>>>> to be defined here) positive and negative guards must be supported.
>>>> If you do not support guards for a particular datatype, then arguably
>>>> you do not support the datatype, so I think that's a reasonable
>>>> requirement.  It is also necessary, for example, for embedding RIF-RDF
>>>> combinations into RIF.
>>>
>>> I am not sure whether this should be part of DTB and we didn't yet 
>>> come up with a clear definition. If people think we need it and 
>>> someone comes up with a reasonable definition, I am very willing to 
>>> include it.
>>
>> 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.

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

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

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

> 
>>>> - 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 woulf rather keep it.

Please include an editor's note in the draft saying that the name is 
still under discussion.

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

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw