RE: Parameterized Inference - starting mail discussion

There seems to be an underlying tension here between the role and responsibilities of the query and the role and responsibilities of the data provider.

A SPARQL endpoint provides access to data via the query language.  Different endpoints can have different datasets and different inference regimes (using the existing BGP extension point).  The data/service provider has a quite active role in determining the facilities available and advertises these through a service description.  

In the parameterized inference feature, it is the query (writer) telling the general purpose query engine what to do.  The data and service have a more passive role and the query writer is controlling the whole process.  This situation is more like important for building applications on web data where there isn’t split of service provider and information consumer.

(This is not to express an explicit opinion for or against)

 Andy

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Axel Polleres
> Sent: 08 April 2009 16:01
> To: 'RDF Data Access Working Group'
> Subject: Parameterized Inference - starting mail discussion
> 
> <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 Monday, 13 April 2009 18:30:53 UTC