Re: [DTB] Most editor's notes addressed

Jos de Bruijn wrote:
> 
> Dave Reynolds wrote:
>> Axel Polleres wrote:
>>
>>> Jos de Bruijn wrote:
>>>> 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.
>> Are there not?
> 
> Correct.
> I did advocate having them as objects in the language, but there was
> some opposition, and I did not persist.

I had forgotten/missed that.

>> In RDF I can and do make statements such as:
>>
>>   xsd:decimal rdf:type rdfs:Datatype.
>>   xsd:integer rdf:type rdfs:Datatype.
>>   eg:number   rdf:type rdfs:Datatype.
>>   xsd:integer rdfs:subClassOf xsd:decimal.
>>   xsd:decimal rdfs:subClassOf eg:number.
>>   ...
>>
>> and use RDF rules to process such statements (e.g. to implement the RDFS
>> D-entailments).
> 
> In RIF you don't need rules to implement D-entailments, because you can
> just use RIF-RDF combinations with the D-entailment profile.

True. That's why I had eg:number in my example to indicate that I might 
be stepping outside the entailments already in the D-entailment profile.

In practice my motivation might be to implement the D-entailment profile 
by rules on top of the simple profile.

> If you use this profile, datatypes are objects in the domain.
> 
>> I would expect to be to express such rules within RIF and that such
>> rules would be able to connect the return value of pred:hasDatatype to
>> the frames representing the above RDF assertions.
>>
>> For example I could write something like:
>>
>>      eg:isNumber(?X) :- pred:hasDatatype(?X, ?I),
>>                              ?I[rdfs:subClassOf->eg:number].
>>
>> If the return value of hasDatatype were xsd:anyURI I could hack my way
>> around it but it would not be convenient or easy to explain to users.
> 
> RIF currently suggests using guard predicates for writing such things.
> 
> But you two did manage to convince me that the second argument of the
> predicate should not be restricted, i.e., it can be an arbitrary object.
> I believe that in that case one gets the expected behavior in RIF-RDF
> combinations with D-entailment.

Right.

>>>> 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. 
>> Seconded.
> 
> I remain unconvinced that we should strive to "emulate" SPARQL's
> filters. First of all, it is unclear what "emulate" means, since the
> languages are completely different.
> Second, in this specific case, it makes sense that RIF "extends" the
> SPARQL filter, because RIF is datatype-aware, whereas SPARQL is not.

Fair comment, the "extension" due to datatype awareness seems acceptable 
to me. I agree this isn't a precise emulation of SPARQL filters but in 
practical terms it seems at least a useful move in that direction.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Friday, 14 November 2008 10:17:33 UTC