- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 24 Feb 2010 01:29:18 -0500
- To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- cc: SPARQL Working Group <public-rdf-dawg@w3.org>
A few thoughts, in advance. Some of this is very much over my head; I'm trying.... > * RIF issues > o Will/should RIF be marked as "at risk" depending on the RIF WG note > about the RIF-to-RDF mapping? What is the status of the RIF to RDF > mapping? Will there be something like rif:import? I'm still hard at work on the mapping. I did a first cut, implemented with round tripping, etc, but it wasn't right in a way I'm not sure how to formally characterize. But I'll try: if you encode a RIF document D with id U in an RDF graph G, and G entails G', and G' contains an encoding of a RIF Document D' with id U, then D entails D'. Maybe D=D'. Less formally, if you put a bunch of RIF documents into a triple store, run "sound" rules over the triple store, and try to extract your RIF documents again, you'll either get something ill-formed or something that's essentially the same as you started with. My first attempt, the "obvious" mapping, has a lot of multi-valued properties. For example the zero-or-more conjuncts for an And term are each connected to the And term by a rif:formula arc. If you simple drop a triple when extracting D, you'll get a ruleset with a completely different meaning. My new version uses a lot of rdf:Lists to avoid this problem. This is a little clumsy viewed as triples, but it has several advantages. It leads to a much more direct object mapping for non-RDF systems, and it makes RIF documents easier to process (correctly) using rules. Anyway, the mapping is perhaps orthogonal to the Ent issue, since graphs which merely describe RIF documents don't have any special semantics. For the semantics, yeah, we want rif:imports, as Axel has mentioned. > o Entailment regimes have to define which graphs the accept. Will the RIF > entailment regime work with all RDF graphs? Different lists in RDF and > RIF? I think all graphs, yeah, at least for some import profiles. > o Will each rule set be an entailment regime, e.g., the SD says something > like: myEndpoint sd:EntailmentRegime <http://example.org/myRules.rif>? > Or is there a suitable RIF entailment relation (RIF+RDF semantics) and > one specifies a rule set in a from clause or in the data set? Which RIF > profiles does that cover? This might affect the condition on extensions > to BGP matching that requires that > SG E-entails (SG union P1(BGP1) union ... union Pn(BGPn)) I'm not following the math, but it seems to me the main thing we want is a single RIF entailment relation, which uses rif:imports in the data to bring in whatever other entailments you might want. There may be an advantage to also allowing the use of names of RIF documents as names of entailment regimes. (I don't actually understand how users interact with entailment regime identifiers, sorry.) > o How are blank nodes defined in RIF? Will skolemization/mapping to RIF > local symbols work as for the other regimes? I think so. > o Not all RIF dialects are based on a model-theory (e.g., RIF PRD), so > they do not come with an entailment relation, but have a procedural > semantics. Can we still use the procedural semantics to define > something like an entailment regime? I sure hope so. When we say "entailment regime" what we really mean is "specification of inference", right? And PRD has a specification of inference, which is all that actually matters. > o Which RIF profiles should be included? Only RIF Core? Does RIF Core > coincide with OWL RDF-Based or Direct Semantics? How many profiles are > there? I hope we don't have to say anything about which RIF profiles (dialects) are included. Certainly we don't want to exclude user extensions. (But, again, I don't understand how users interact with this spec.) > o What effects do the non-monotonic features of some RIF dialects have? > E.g., RIF PRD and (anticipated) RIF dialects with default negation. > How does that interact with SPARQL's non-monotonic features? > This probably affects issue-43: Should entailment-regimes be declared > over the whole dataset or individual graphs? Eeeeek, scary stuff. Still, for PRD, I think it's easy to just say you're querying over the state of the system after running all the rules to completion. If someone does a logical non-mon RIF dialect, that could be more dangerous. > o RIF production rules: it is no even clear how conjunctive queries work. Just query over the completed state, yes? > o What is our timeline for RIF? Soon? :-) RIF is trying to get to REC in a very small number of months (like 2). One little concern I have is Condition 4. I don't see how one can possibly define a finite answer set for RIF. For example, given the document: if p(?n) then p(?n+1). p(1). and the query p(?x). well, I don't think there's any sensible way to limit this to a finite set of answers. Is there? Maybe we can just say such things are pathological and we don't define what the answer set might be? But there might be perfectly reasonable, important, useful, working rulesets that have infinite answers.... Thinking... Oh, sure, you could have a rule which defines a predicate odd(...), which is true for odd integers and false for even integers. ask odd(17) makes perfect sense; query odd(?x) has infinite (very well defined) answers. -- Sandro
Received on Wednesday, 24 February 2010 06:29:20 UTC