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? 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? 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.
Would you mind giving a concrete example...

> 2/ bnodes!

... also for that one?

> 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 18:17:25 UTC