[DTB] status and (Re: a few comments about DTB)

Thanks Jos for his comments!

So far, I have implemented most of the changes mentioned in the F2F, 
just the rewording in the abstract and introduction of section 2 are 
missing.

As I am travelling from tomorrow on, I will very likely not be able to 
do more before the weekend. Anyway, as mentioned above most of the 
changes requested at the review are ready for review and I will be able 
to include Jos' comments together with the next review round.

best,
Axel

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.
> - 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.  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.
> - section 4.3, casting:
> The casting functions are under-defined:  1 It is unclear for which data 
> types these functions are defined.
> 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.
> 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.
> 4 rif:XMLLiteral -> rdf:XMLLiteral (in several places in the document)
> 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].
> 
> - I wonder what the justification is for just retaining the language in 
> the cast from text to string
> - section 4.7: I don't really like the name of the function ("lang"); 
> 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


-- 
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, 30 May 2008 18:23:06 UTC