Re: [DTB] Most editor's notes addressed

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

Ok:
it does not, for your own dialect, it does if it is a W3C endorsed 
dialect. (and: no, I do not have a formal definition of "W3C endorsed 
dialect" in mind yet, and yes "it should be discussed again.")





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

indeed, i agree... that's exactly the problem: SPARQL allows me to do 
that, RIF doesn't.

>>    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 was hoping we could get BLD a usable rules language for RDF, 
compatible with SPARQL. (And similar problems will arise if we pursue to 
suggest RIF to the RDB2RDF people: If we as a working group approach 
them and say: look at RIF, we should then not be in the position that, 
if they agree to do so, having to answer them: "BUT, BTW RIF doesn't 
work for that, you need to do your own dialect from scratch, your 
problem...")

I see some very fundamental issues here.


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

Hmm, I agree, another solution is to define different conformance 
notions. Anyways, in case I had to decide for one, I am in favor of then 
going for  the option to take the proposed view in rdf:text, section 3.1 
in RIF, i.e. to view xs:string type as subtype of rdf:text. We 
diuscussed that lengthly in the text task force and didn't see any major 
problems with that. rdf:text shall be understood as an *extension* of 
xs:string, not as something disjoint.

So I will leave it as is, keeping the Ed note, until we have found a 
resolution.

> Best, Jos

cheers,
Axel

> 
>>> 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 18:07:15 UTC