W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2008

Re: [DTB] Most editor's notes addressed

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 14 Nov 2008 09:31:11 +0000
Message-ID: <491D455F.3000702@deri.org>
To: Dave Reynolds <der@hplb.hpl.hp.com>
CC: Jos de Bruijn <debruijn@inf.unibz.it>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

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

Side remark: there is no "return value" for hasDatatype, it is a 
predicate, see other mails and example in the draft.

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

Agree! that was my rationale as well.

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


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Friday, 14 November 2008 09:31:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:58 GMT