Re: [DTB] Most editor's notes addressed

Axel Polleres wrote:
> Jos de Bruijn wrote:
>> 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 would be very interested in your response to my questions....


>>
>>>> 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.
> 
> I disagree.... if not for the cause than at least for the symtoms:
> 
> I can do the following in SPARQL (selecting all OBJECTS which are of the
> same type as a certain literal's datatype)

You just filter tuples based on some syntactic criteria. This has
nothing to do with abstract objects in RIF structures.

> 
>    SELECT ?X ?Y
>    WHERE { ?X a ?DT
>            :s :myDatatypeProperty ?L.
>            FILTER ( ?DT = datatype( ?L ) }
> 
> 
> 
> 
>>>> 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. 
> 
> In my optinion it is a big problem, because:
> 
> 1) RIF shall be a rule EXCHANGE format.
> and CONSTRUCT queries, just as views in databases have a "rules
> reading". If I can't use RIF to exchange this, I would consider this a
> failure or at the very least a weaakness of RIF.
> 
> 2) It prevents a SPARQL/Turtle style syntax for a dialect of RIF, which
> is one of my goals, towards an attractive syntax for the RDF crowd.
> 
>> The former is just an algorithm that does some symbol
>> manipulation. The latter is a proper logical language.
> 
> Not all rules languages are purely logical.

RIF BLD is.

> 
>>>> 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.
> 
> The value space of DTB is not defined in DTB but in the rdf:text spec.
> It says nothing about the disjointness. Section 3.1 of the rdf:text-spec
> leaves it to the spec/implementation to chose which way to view the
> string value space:
> 
> "To overcome this difficulty, specifications that use rdf:text MAY
> choose to interpret the datatypes from the following list in a slightly
> different way. The resulting datatypes have value spaces that are
> isomorphic with the value spaces from XML Schema Datatypes [XML Schema
> Datatypes], but that are subsets of the value space of rdf:text."

This refers to specifications (like the OWL 2 or RIF BLD spec), not
implementations.

> 
> Section 1.3 of DTB has an explicit mention that "RIF implementations MAY
> choose to interpret xs:string and its subtypes as subtypes of rdf:text
> following Section 3.1 of [RDF-TEXT], i.e., interpreting strings as texts
> with an empty language tag."

I did not catch that.
Please remove this text, because it makes the specification ambiguous.
Each data type must have one value space; we cannot leave it up to
implementations to pick a value space; this would impede interchange.

Best, Jos

> 
>> These value spaces are *disjoint*. Period.
> 
> You read the spec, please. Period. ;-)
> To help you find those related paragraphs, I duplicated the Ed note
> 
> "{{EdNote|text=Whether or not we allow the treatment of
> <tt>xs:string</tt> as a subtype of <tt>rdf:text</tt> in RIF
> implementations is still under discussion, cf. the mail thread starting
> at http://lists.w3.org/Archives/Public/public-rif-wg/2008Nov/0067.html.}}"
> 
>  in Section 1.3 ;-)
> 
> cheers,
> Axel
> 
>>>> 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