Re: a few comments about DTB

Jos de Bruijn wrote:
> PS the following text in section 4.1 does not make sense:
> "naming convention we use the capitalized non-prefix XML local name part 
> denoting the data type"
> for example, rif:text and rdf:XMLLiteral do not have a local part, since 
> they are not XML names; they are absolute IRIs.

You are giving me a hard time on this, I think this is pretty obvious.
The prefixes are defined in section 1 of the document. what I mean to 
say is what remains when you cut of from the datatype IRI this prefix.

> I think that when defining datatypes in section 2.2 you should define 
> the short names: every datatype has a short name, starting with a 
> capital letter. 

To add a formal definition for the naming convention here is IMO 
"overkill"  (may be good for a mathematical article or textbook, but I 
think in this document it is sufficiently clear as is now, honestly.
Matter of taste, other opinions welcome, for the moment I rather leave 
this, we anyway have an editor's note about the naming convention already.

> For the XML schema datatypes, this short name is the 
> capitalized version of the name (notice it in XML schema, datatype names 
> are not IRIs, and do not have a namespace).

no, we are talking about RIF data types in this document, not about
XML schema data types, these *do* have a unique IRI:

"Each symbol space has an associated lexical space and a unique IRI 
identifying it."
[...]
"Data types in RIF are symbol spaces which have special semantics."

For the XML SChema data types we reuse we use the IRIs as mentioned in 
Section 2.1.

>  For rif:text it is Text and 
> for rdf:XMLLiteral it is XMLLiteral.
> 
> Finally, you can define the guard predicates for all datatypes in 
> section 4.1, also for the user-defined datatypes.  I guess you already 
> do so, since the definition of the schema and the semantics are already 
> general.
> I actually do not really understand why you duplicate the schema 
> definitions in the subsections of 4.1.

The rationale is: For reasons of completeness, for each defined function 
or predicate in the document, at least the schema is listed. Intended 
domain and mapping are only listed when not clear from the context.

cheers,
Axel

> Best, Jos
> 
> Jos de Bruijn wrote:
>>>>>> 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.
>>
>> Requiring implementing guards for datatypes is really a conformance 
>> issue, and the conformance statement currently in BLD does not require 
>> guards to be implemented for supported every datatype, and I think 
>> that is fine.
>> I do think that guards need to be defined for every datatype. If one 
>> wants to use these guards, one can do so.  But one can only share the 
>> rule sets that use of such guards with consumers that support the 
>> guards, which is fine, I think.
>>
>> Best, Jos
>>
>>>
>>>>>>>> - 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 14:02:31 UTC