RE: Parameterized Inference - starting mail discussion



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Axel Polleres
> Sent: 14 April 2009 09:14
> To: Orri Erling; 'RDF Data Access Working Group'
> Cc: 'Bijan Parsia'
> Subject: Re: Parameterized Inference - starting mail discussion
> 
> <chair-hat-off>
> Orri, all,
> 
> I agree with the observation that full inference (even RDFS) may be
> harmful in the context of Web data, see also [1].
> 
>   Unfortunately, I didn't manage to separate the issues on the wiki yet,
> but I suggest, in connection with parameterized inference to put the
> following four items to strawpoll, trying to summarize Bijan's/Andy's
> suggestions:
> 
> - ADVERTISE ENTAILMENT: should we work on a mechanism to specify the
> entailment regime supported by an engine (endpoint side parameterized
> inference, i.e. the endpoint be able to specify what entailment it
> supports)

= Feature:ServiceDescriptions ?

else -1.

> 
> - REQUEST ENTAILMENT: should we work on a mechanism to request the
> entailment regime in a query (query side side parameterized inference,
> i.e. the requester be able to specify what entailment it expects, Bijan
> seemed to have suggested that the engine may respond falling back to
> another entailment regime, which probably should be indicated in the
> query response)

-1 : Too early. Do the important, well understood, well explored features first.  SPARQL already has an extension point on BGP matching. Use this and other extension mechanisms to explore this area.  Much already possible, maybe inconveniently and not ideally, with named graphs and different endpoint setups over the same base data.

> 
> - SUPPORTED ENTAILMENT REGIMES: should we work on defining a fixed set
>    of supported entailment regimes (suggested were: OWL RL, OWL EL, OWL
> QL, OWL DL, "finite RDFS") plus an extensibility mechanism for custom
> entailment regimes (Orri's mail seems to support this, i.e. not all
> inferences wanted in all situations, suggested so far was <rifruleset>
> but maybe even more flexibility is needed)?

-1 : The community should cluster around particular profiles based on experience.  Then record and standardise.  

> 
> - EXTENDED DATASETS: should we work on defining an extended mechanism
> for defining datasets that allows to merge/compose named graphs? This
> relates to paramterized inference because you need to be able to "merge"
> an ontology into a "named data graph" for getting inferred answers.

Service descriptions can say "graph X is the RDF merge of graphs Y and Z" which leaves the case of query control of composition.

This is non-trivial when the graphs are large.  See also Feature:BasicFederatedQuery which allows dispatch of sub-queries to other graphs rather than merging them.

For this round of WG work, I'd scope SPARQL to not cover how graphs and datasets come into being.  Also, I don't see where this stops.

 Andy

> 
> 
> My strawpoll vote would be +1 for all of these, although I could imagine
> that e.g. SUPPORTED ENTAILMENT REGIMES could go into a note rather than
> Rec track, if that is preferred.
> </chair-hat-off>
> 
> Axel
> 
>

Received on Tuesday, 14 April 2009 13:35:58 UTC