Re: [DTB] Most editor's notes addressed

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?

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

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.

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

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

Received on Friday, 14 November 2008 09:19:05 UTC