Re: [DTB] Most editor's notes addressed

jos, thnx again,

responses as far as possible. Whatever I couldn't tackle now, I resolved 
by re-adding ed notes.

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

We discussed it in the last telecon.

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

I had that, but I went back from it, since I wanted to maintain a 
minimal degree of compatibility with SPARQL's datatype function (which 
does return an IRI, and not an xs:anyURI typed literal). We had to do 
all kinds of work-arounds to get to some version where we can 
"more-or-less" emulate SPARQL's filter functions in RIF. I am reluctant 
to deviate even further. If the minimal requirement to emulate SPARQL's 
filter functions in RIF is not met, I personally would consider RIF 
failed. Actually, I would opt for adding it to our official requirements 
and work on it more.

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

yes, I am aware of this, but I don't see the fundamental problem with 
it... the fundamental one is a different problem:

I have *no* means to adequately emulate SPARQL's datatype function in 
RIF. For instance the simple query

  CONSTRUCT { ?X ex:sameDTas ?Y }
  WHERE { ?S1 ?P2 ?X . ?S2 ?P2 ?Y
          FILTER (datatype(?X) = datatype(?Y) )
        }

cannot adequately be emulated with that current predicate, and I see 
currently NO way to get there. Opinions welcome.

> I think that's not good, and can be
> avoided by returning URIs instead of abstract objects.

... or at least, I don't see how your proposal alleviates the problem.

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

Cf. Section 3.1 of the rdf:text document.
The possiblity of treating xs:string as a subtype of rdf:text was one of 
the major achievments of the rddf:text task force, since it has the 
potential to clean up the mess left by the undesirable scism between
plain literals and language tagged literals, providing an umbrella for 
them.


> I would suggest using an example with numbers.

I added one and I added an ed note here for the moment to point to the 
problems discussed in the present mail.



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

I have no time to address this in more detail now, I thought that what 
is there now was clear enough. For the moment, I re-added the ed note, 
let's discuss it in the group.

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


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Thursday, 13 November 2008 12:56:39 UTC