Re: a few comments about DTB

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

reformulated.

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

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.

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


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.

Received on Monday, 23 June 2008 06:57:53 UTC