Re: a few comments about DTB

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

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.

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

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.

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

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

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

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

> - section 4.7: I don't really like the name of the function ("lang");

I do. This is also used in SPARQL.

> 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 Tuesday, 10 June 2008 18:37:40 UTC