Re: [DTB] Most editor's notes addressed

Responses in line.

Axel Polleres wrote:
> 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.

Perhaps I was not paying enough attention. Sorry for that.

In any case, I don't see a working group resolution, so I think it
should be discussed again.
I am willing to make the case for allowing guard predicates of the form
pred:isDT for at least the XML schema datatypes.

Actually, I am a little bit confused by the text. I actually don't
really understand what a dialect is. I believe there is no definition.

If I use BLD with non-strict conformance, and decide I want to use the
xsd:int datatype, am I using BLD or am I using a dialect? Is this
dialect a W3C dialect or a third-party dialect?
And suppose now that I want to use a guard predicate. Does the above
text or does the above text not allow me to use the name pred:isInt?

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

Wait a minute! IRIs in SPARQL do not denote abstract objects, like they
do in RIF. They are just syntactical objects. So, returning IRIs is
*much closer* to what SPARQL does than returning abstract objects.

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

This is not a problem. SPARQL and RIF BLD are simply different
languages. The former is just an algorithm that does some symbol
manipulation. The latter is a proper logical language.

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

Read the DTB document. Read the definitions of the value spaces of
rdf:text and xs:string.
These value spaces are *disjoint*. Period.

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

This is just a matter of fixing the definitions. I don't think this
needs any discussion; this would only delay publication.

Best, Jos

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