- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 14 Nov 2008 10:06:22 +0000
- To: Axel Polleres <axel.polleres@deri.org>
- CC: Jos de Bruijn <debruijn@inf.unibz.it>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Axel Polleres 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? >> >> 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. Yes I know, I was using that as shorthand for "what gets bound to the second argument of the predicate" as in the example below. Dave >> 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 > >
Received on Friday, 14 November 2008 10:07:10 UTC