Re: [DTB] Most editor's notes addressed

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

    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.

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

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

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


-- 
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 14:56:20 UTC