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: Tue, 17 Jun 2008 08:40:45 +0200
Message-ID: <48575C6D.1070106@inf.unibz.it>
To: Axel Polleres <axel.polleres@deri.org>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

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


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

Received on Tuesday, 17 June 2008 10:03:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:45 UTC