W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Parameterized Inference - starting mail discussion

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 08 Apr 2009 16:01:16 +0100
Message-ID: <49DCBC3C.60101@deri.org>
To: 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
<chair-hat-off>
Hi,

since I cannot participate due to travelling in the next teleconf most 
likely, I'd like to start discussing this feature on the list.

http://www.w3.org/2009/sparql/wiki/Feature:ParameterizedInference

The feature proposed has - strictly speaking - two parts.

1) parameterizing the inference regime in queries

2) an extension of the dataset specification features to allow for 
parameterizing ontologies to be taken into account for any of the graphs 
in the dataset

(3) there is a third thing mentioned in the wiki page which relates to 
2) about allowing recursive ftching of named graphs when the dataset is 
given implicitly.

Let me add some explanations beyond the wiki page on these feature(s):

1) USING RULESET is closely related to the OWL inference discussed 
yesterday, but simpler. Instead of specifying an entailment regime for 
one of the OWL dialects, the idea is to allow a very pragmatic reference 
to a ruleset specifying a finite set of RDF inference rules being 
expected to be evaluated on the query. The suggestion here is to be able 
to either refer to some fixed rulesets which we endorse with some public 
identifier, e.g.

   USING RULESET RDFS

could refer to a fixed ruleset implementing the informal rdfs inference 
rules in the RDF Semantics spec. or (preferrably) a finite subset of it, 
i.e. it would for obvious reasons probably not be advisable to allow 
infinite axiomatic triples and alike. Alternatively, one could specify a 
ruleset in a rule format for interchanging inference rules (RIF being 
the natural candidate) dereferenceable at a URL. i.e.

   USING RULESET <myinferenceRules.rif>

myinferenceRules.rif could, for instance be a ruleset only specifying
listmembership infernce, as proposed in
http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists

  e.g. could be done by the following ruleset:

    {?list sparql:listMember ?member.} IF {?list rdfs:first ?member.}
    {?list sparql:listMember ?member.} IF {?list rdfs:rest ?r. ?r 
sparql:listMember ?member.}

Remark: the RIF presentation syntax is in this respect (whether it 
allows N3 style notation) not yet fixed, but that should be 
understandable to the SPARQL crowd, I guess.

Likewise, a link to such RIF rulesets could be used to advertised the 
supported inference by a SPARQL endpoint if we go towards service 
descriptions. This is along the lines of seeral systems supporting 
inference rules, but using their own rules languages, where representing 
them in an exchange format would be desirable. In that sense, there 
exist implementations such as Jena, OWLIM, but they do not (yet) support 
the suggested syntax.

2) USING ONTOLOGY

Now, if I want to support inference, I also want to support ontologies 
(even if they are not explicitly imported in a graph via owl:imports), 
that e.g. I want to see that I want to use the foaf ontology for 
inferencing on queries over foaf files. Now, as soon as I stay in the 
default graph, all is fine, I can simply merge the foaf ontology into 
the def graph, e.g.

  FROM myfoaf.rdf
  FROM yourfoaf.rdf
  FROM foaf-ontology.rdf

BUT, in connection with named graphs I cannot merge graphs expclicitly!
that is, if I specify

  FROM NAMED myfoaf.rdf
  FROM NAMED yourfoaf.rdf
  FROM foaf-ontology.rdf
  WHERE { ... GRAPH ?x { .HERE. } }

HERE, the foaf ontology is not in part of the scoping graph and thus not 
relevant for (even if supported) inferences.
That is why we suggest the keyword
    USING ONTOLOGY <IRI>
which basically says that its argument "merges" into each named graph.
The ability to construct named graphs as merge of other graphs, as also 
outlined in
  http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets
would be an alternative path to achieve this, though mor cumbersome to 
write, but more flexible.

3) In the context of 2) what also becomes relevant is that an explicitly 
given dataset cannot be dynamically extended. A sample query needing 
that support is:

SELECT NAMES OF ALL PEOPLE I KNOW FROM MY FOAF FILE OR NAMES OF PEOPLE 
KNOWN BY THESE PEOPLE ACCORDING TO THEIR FOAF FILES THAT ARE LINKED FROM 
MINE BY rdfs:seeAlso LINKS

This could be achieved by several ways, I proposed in the feature list
FROM NAMED ALL
which would enable recursive fetching of named graphs.
Alternatives Could be to allow nesting of CONSTRUCT queries in FROM or 
FROM NAMED clauses.

Though these features are all somewhat overlapping, it may make sense to 
do separate strawpolls for each one.
</chair-hat-off>

<chair-hat-on>
Others might follow the example of triggering a disussion on the 
remaining features on the list, if they champion them
</chair-hat-on>


cheers,
Axel
Received on Wednesday, 8 April 2009 15:01:56 GMT

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