RE: Re 2: [TF-ENT] Querying datasets with default plus named graphs

> -----Original Message-----
> From: Axel Polleres [mailto:axel.polleres@deri.org]
> Sent: 17 October 2009 17:02
> To: Seaborne, Andy
> Cc: Birte Glimm; Ivan Herman; SPARQL Working Group
> Subject: Re: Re 2: [TF-ENT] Querying datasets with default plus named graphs
> 
> > Not the implicit closure.  The one I think is important and have
> > seen done (we recommend the approach as the question comes up
> > regularly on jena-dev) - the same base data available in one named
> > graph with no (=simple) entailment and also one (named) graph with
> > the rules engine or Pellet behind it.  There are various use case
> > but one is the desire to access asserted and inferred class
> > relationships.
> >
> >         Andy
> 
> But that is complementary, isn't it? 

No.

As I see it, defining cross-graph semantics for anything is a significant task.  The extension point in SPARQL is BGP matching, not implicit definition of the graph being queried.  So it's priorities and timescale.

> Do you have some links for use cases on this?

jena-dev archives!

> What's the difference/benefit against having separate endpoints (at
> lease from the outside) one supporting simple
> and one with RDFS Entailment?

Because
1/ you want to do one query request with both accessible (e.g. direct subclasses)
2/ bnodes!

> I ask, since there is an interesting
> point here, that your setting can't be
> described with one entailment regime per endpoint...  and that
> possibly affects service description:

Correct - description should per graph.  This is important in other possibilities when different graphs are backed by different storage layers with different characteristics (e.g. degree of D-entailment).

> IIRC, we didn't discuss entailment regime per graph level in terms of
> service description as of yet, but I think the tacit assumption
> behind (cf. Service Description [1])
> 
> sd:supportedEntailment
>  domain: sd:Service
>  range: sd:EntailmentRegime
> 
> was that the entailent regime is fixed for all graphs the same at one
> endpoint.

http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0015.html


 Andy

> 
> 
> best,
> Axel
> 
> 1. http://kasei.us/2009/09/sparql/sd.txt

> 
> On 17 Oct 2009, at 16:43, Seaborne, Andy wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Axel Polleres [mailto:axel.polleres@deri.org]
> > > Sent: 13 October 2009 14:29
> > > To: Seaborne, Andy
> > > Cc: Birte Glimm; Ivan Herman; SPARQL Working Group
> > > Subject: Re: Re 2: [TF-ENT] Querying datasets with default plus
> > named graphs
> > >
> > >
> > > On 13 Oct 2009, at 08:50, Seaborne, Andy wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> > > > request@w3.org]
> > > > > On Behalf Of Axel Polleres
> > > > > Sent: 12 October 2009 23:45
> > > > > To: Birte Glimm
> > > > > Cc: Ivan Herman; SPARQL Working Group
> > > > > Subject: Re: Re 2: [TF-ENT] Querying datasets with default plus
> > > > named graphs
> > > > >
> > > > > (catching up too slow recently ...  :-/)
> > > > >
> > > > > +1 to "identify the status as is (limited usefulness of named
> > > > graphs)
> > > > > and pointers to solutions how this could be fixed (either as
> > > > > concrete suggestions for extension marked at risk or just an
> > > > > informative suggestion of future extensions)"
> > > >
> > > > -1: this text is judging the issue.
> > >
> > > hmmm, I agree that  "(limited usefulness of named graphs)" is
> > judging,
> > > indeed.
> > > but we should note the issue (in a more neutral wording maybe), yes?
> > >
> > > > It was not an objective of the TF to make datasets work with
> > > > entailment (for some definition of "work" that has not been
> > > > articulated).
> > >
> > > we had already discussed CompositeDatasets
> > > (http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets

> > > )
> > > which were not among the favorite/chosen features.
> > >
> > > >  Note: I want the mixed entailment case to work because that is
> > > > deployed practice.
> > > >  Let's note that BGP RDFS-entailment currently requires all the
> > > > triples in the graph (it's most obvious given the informative RDFS
> > > > Entailment Rules in RDF-MT anyway).  It would be something else
> > (and
> > > > useful) to have entailment work with a background vocabulary.  The
> > > > rules entailment regime will give us that, maybe others, so I
> > don't
> > > > see there is a problem.
> > >
> > > yup, it is complementary.
> > >
> > > >
> > > > A graph in a dataset can be the union of other graphs in the
> > dataset
> > > > so having one graph as the union of vocabulary and data is already
> > > > possible and done in practice but it's just not the only way that
> > > > things can be setup.
> > >
> > > that's what I tried to illustrate with the "implicit closure"
> > approach
> > > mentioned in the last mail, yes.
> > > which approach did you mean here with "possible and done in
> > practice"?
> > > that one?
> >
> > Not the implicit closure.  The one I think is important and have
> > seen done (we recommend the approach as the question comes up
> > regularly on jena-dev) - the same base data available in one named
> > graph with no (=simple) entailment and also one (named) graph with
> > the rules engine or Pellet behind it.  There are various use case
> > but one is the desire to access asserted and inferred class
> > relationships.
> >
> >         Andy
> >
> > >
> > > best,
> > > Axel
> > >
> > > >  It seems to me that we are trying to force one model of dataset
> > for
> > > > one situation on all possible uses, entailment and non-entailment
> > > > related.
> > >
> > >
> > > >
> > > >         Andy
> > > >
> > > >
> >
> >

Received on Saturday, 17 October 2009 16:45:50 UTC