Re: a few comments about DTB

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

what about e.g. "is-string"? better?

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

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

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

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

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

>>> - 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.
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 Friday, 13 June 2008 11:39:00 UTC