Re: [DTB] Most editor's notes addressed

> 
> 3)
> "Editor's Note: The naming convention for guard predicates, particularly
> whether third parties defining their own datatypes should be
> encouraged/discouraged to reuse the standard <tt>pred:</tt> and
> <tt>func:</tt> namespaces to define their own built-in predicates and
> functions, are still under discussion in the working group."
> 
> Fixed (and likewise for negative guards), added:
> 
> "Parties defining their own datatypes to be used in RIF exchanged rules
> may define their own guard predicates for these datatypes. Labels used
> for such additional guard predicates for datatypes not mentioned in the
> present document MAY follow the similar naming convention where
> applicable without creating ambiguities with predicate names defined in
> the present document. Particularly, upcoming W3C specifications MAY, but
> 3rd party dialects MUST NOT reuse, the <tt>pred:</tt> and <tt>func:</tt>
> namespaces for such guard predicates."

Was this a working group decision?
I think this is a very bad idea. I think people should be encouraged to
use the same naming convention for guard predicates as is done in DTB.
For example, if someone wants to use the xs:int data type, you should be
allowed to use pred:isInt as name of the guard predicate.

> 
> 4)
> Section
> "== Cast Functions and Conversion Predicates for Datatypes and
> <tt>rif:iri</tt> =="
> 
> renamed to:
> 
> "== Datatype Conversion and Datatype Checking =="
> 
> in order to resolve:
> "Editor's Note: It was noted in discussions of the working group, that
> except guard predicates, also an analogous built-in function or
> predicate to SPARQL's datatype function is needed. This however has some
> technical implications, see
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0096.html."
> 
> I added a new pred:hasDatatype predicate here, please check, especially
> Dave (since I didn't find your mail on that, I am not sure whether this
> was how you intedned it, but this is how it makes sense to me)!

Only data values can have data types, so the domain of the first
argument should be the union of the value spaces of all data types under
consideration.

Then, I find it odd to use an abstract object as data type IRI. I would
suggest to use xsd:anyURI or xsd:string.
There are no actual objects in the interpretation that represent the
data type, so you cannot return the data type itself. I think returning
the datatype IRI is the next best thing.

To see why this is practical consequences consider the constant

"1"^^xs:int

You would like to retrieve the URIs xs:int, xs:integer, xs:decimal, etc.
however, if it is known that a=xs:decimal, for some URI a, you will also
retrieve a in your semantics. I think that's not good, and can be
avoided by returning URIs instead of abstract objects.

Then, the example given below the specification is odd.
you talk about RIF implementations treating xs:string as a subtype of
rdf:text. However, such an implementation would not be conformant,
because it does not correctly implement the data types, since xs:string
as not a subtype of rdf:text.
I would suggest using an example with numbers.

> 
> 
> 5)
> Editor's Note: Conversion from <tt>rif:iri</tt> to <tt>xs:string</tt>
> and vice versa is still under discussion in the working group since
> <tt>rif:iri</tt> is not a datatype. For details, we refer to
> [http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0032.html
> Issue-61]. The following is a strawman proposal which might still change
> in future versions of this working draft.}}
> 
> done: Renamed pred:iri-to-string to pred:iri-string
> 
> 6)
> "Editor's Note: In the following, we adapt several cast functions from
> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]. Due to the
> subtle differences in e.g. error handling between RIF and
> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]], these
> definitions might still need refinement in future versions of this draft."
> 
> done: removed the general remark on casts in the beginning of that
> section and added the agreed predicates.

This issue is not resolved.
There is still a number of problems with the definitions of the casts:
- it is unclear what the word "castable" means. In fact, it is not used
in the referenced specification. You should refer directly to the table
in the specification and use the terminology used there (S/T, etc.)
- what is an "intended domain"? Don't you mean "domain"?
- the domain of a cast function X is the *union* of the value spaces of
the datatypes for which casting to X is supported according to the table
http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-to-primitives-table
[Please link directly to the table]. a value space includes all its
subsets, so it's meaningless to talk about them.
- the concept of some value being the "conversion of" another value is
not defined in the mentioned section. In addition, there is no reason to
be so imprecise in the mappings. Each cast function should refer to the
precise location of the definition in the F&O spec.
E.g.,
Iexternal( ?arg1; xs:double ( ?arg1 ) )(s1) = TV such that ST is
the highest XML schema datatype in the hierarchy [link] that has s1
in its value space and TV is as defined in
Section
<a href="http://...#casting-to-double">17.1.3.2
Casting to xs:double</a> of F&O
- it is unclear what is meant with "the argument value is outside ...
partial conversions". the value is either in the domain of the cast
function, or it is not. The domain needs to be defined appropriately.


> 
> 7)
> "Editor's Note: We might split this subsection into separate subsections
> per casting function in future versions of this document, following the
> convention of having one separate subsection per funtcion/predicate in
> the rest of the document. However, it seemed convenient here to group
> the cast functions which purely rely on XML Schema datatype casting into
> one common subsection."
> 
> done: I split it.
> 
> 
> 8)
> " Note that the subtypes of <tt>xs:integer</tt> do appear in the
> conversion table in
> [http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-from-primitive-to-primitive
> Section 17.1] of
> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]..
> Conversions from and to subtypes of <tt>xs:integer</tt> follow the same
> considerations as <tt>xs:integer</tt> in that table, by the XPath,
> XQuery type hierarchy in
> [http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#datatypes
> Section 1.6] of
> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]."
> 
> I removed that, we aren't talking anymore about the subtypes of
> xs:integer in the document.
> 
> 9)
> "Editor's Note: The cast from <tt>rif:text</tt> to <tt>xs:string</tt> is
> still under discussion, i.e. whether the lang tag should be included
> when casting to <tt>xs:string</tt> or not."
> 
> Casting to xs:string:
> 
> I changed the indented domain from:
> 
> "The union of the value space of <tt>rdf:text</tt> with the value spaces
> of datatypes castable to <tt>xs:string</tt> according to
> [http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-from-primitive-to-primitive
> Section 17.1] of
> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]."
> 
> to just:
> 
> "The value spaces of datatypes castable to <tt>xs:string</tt> according
> to
> [http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-from-primitive-to-primitive
> Section 17.1] of
> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]."
> 
> For conversion/extraction from rdf:text, the extraction functions shall
> be used.... note: string-casts from rdf:text are thus no longer possible
> however!

Excellent!


Best, Jos

> 
> 10) I removed the rdf:text cast function.
> 
> 
> Will work on the remaining 6 Editor's notes shortly.
> 
> Axel
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster