Re: a few comments about DTB

Axel Polleres wrote:
> 
> Jos de Bruijn wrote:
>> Axel,
>>
>> 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.

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

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

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

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

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

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

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

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

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

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