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 19:17
> To: Seaborne, Andy
> Cc: Birte Glimm; Ivan Herman; SPARQL Working Group
> Subject: Re: Re 2: [TF-ENT] Querying datasets with default plus named graphs
> 
> > No.
> >
> > As I see it, defining cross-graph semantics for anything is a
> > significant task.
> 
> Yes, sure, was this (seriously) proposed? 

There is issue 43 -- can we close that now?

> I understood the discussions
> o far that we all agree on that point.
> cross-graph semantics is a whole different issue indeed and not a road
> I would (neither personally nor
> as chair) like to go.
> 
> 
> > The extension point in SPARQL is BGP matching, not implicit
> > definition of the graph being queried.  So it's priorities and
> > timescale.
> 
> +1
> 
> Sure, but that's orthogonal to what we discuss here, isn't it? 

Technical point:
I don't see how it can be - if the dataset description influences, by spec, the outcome of a BGP then it's not orthogonal. (Dataset descriptions can't describe all dataset situations even in SPARQL 1.0.)

> I just
> wanted to raise that *different entailment
> regimes* for *different graphs* is something not covered by current
> SD, but seems to be something present in your use case.
> 
> > > 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)
> 
> direct subclass would need only simple, right?
> I am still trying to understand/find a  UC where I need both in one
> query.

The ability to ask both direct and inferred relationships and compare (e.g. negation!). 

> Would you mind giving a concrete example...
> 
> > 2/ bnodes!
> 
> ... also for that one?

In some implementations, the bnodes will be the same internal id across two views of the same data.  A query doesn't need to re-find a bnode.

It's not something I do but it is something I see done.

 Andy

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

> 
> you mean you raised the issue already, yes? sorry for being slow here.
> FWIW, as mentioned above: totally fine! a concrete example would be
> good though.
> 
> best,
> Axel
> 
> 
> On 17 Oct 2009, at 17:43, Seaborne, Andy wrote:
> 
> > > -----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

> 
> as mentioned above, totally fine, a concrete example would be good
> though.
> 
> >         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 19:18:50 UTC