- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Wed, 04 Jul 2007 16:20:21 +0100
- To: axel@polleres.net
- CC: Jos de Bruijn <debruijn@inf.unibz.it>, RIF <public-rif-wg@w3.org>
Axel Polleres wrote: >>> - how we'd deal with results of rule(set)s? ie. if we have a frame >>> s[p->o] in the head of a rule (where s,p,o is a variable skolem >>> term, literal, iri, etc), it might well not be a valid RDF >>> triple, so my question is, for N3 like rules, how would we ensure >>> that the result is getting back to RDF again. Do we need/want that? >>> >>> (Here, e.g. SPARQL takes the approach >>> to simply ignore all non RDF triples, and only consider valid RDF >>> triples as consequences) >> >> >> Here, again, SPARQL uses an ugly syntactic means for getting rid of >> non-well-formed RDF: triples with literals or bnodes in inconvenient >> places are simply discarded. I would argue that we do not want any such >> arbitrary filtering in RIF. > > Hmmm, but what's the alternative? > >> In any case, I do not think it is up to this working group to decide how >> people should construct RDF graphs from query answers obtained using >> rules exchanged with RIF. > > If we see the interoperation with RDF only one-way then yes, but I am > not sure whether all of the WG like that (I myself would, apart from > possible technical difficulties love to have the possibility to export > rules results/models/inferred atoms back to RDF) I don't think RIF should limit the ability of rules to construct triples which violate the RDF syntactic restrictions. There are two reasons for this: 1. The RDF Core working group envisaged that a future revision of the RDF spec might lift some of those restrictions and designed the semantics to make this possible. This was particularly in reference to the restrictions on literals which are an accident of the RDF/XML syntax. There is no such revision currently scheduled but it is certainly a future option to be aware of. 2. Practice shows that rulesets, including the RDFS closure rules, that violate those restrictions can be useful. For example, look at the rules 5a and 5b of the rhoDF paper already discussed. Those are not needed in systems which allow unrestricted intermediate triples to be deduced. In terms of the reverse transformation then I think we should define the reverse transformation but leave it up to processors how to handle syntactically ill-formed triples. I.e. a processor would be free to filter syntactically ill-formed triples, abort processing or continue processing if targeting a language with fewer restrictions (e.g. N3 permits literals in subject and predicate positions). Dave -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Wednesday, 4 July 2007 15:20:42 UTC