Re: [DTB] Most editor's notes addressed

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.

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

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

Best, Jos

> 
> Dave

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