W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: [TF-ENT] Agenda 24th Feb teleconf

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>
Message-ID: <10353.1266992958@waldron>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT