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

On 17 Oct 2009, at 19:16, Axel Polleres wrote:

> > 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.


P.S.: I realise thanks to Andy that I should clarify here:
Implicit closure is not cross-graph semantics and I did not mean to  
propose it here
as something we should standardise, but just something which existing  
systems do inline with linked
data best practices.
  I was just raising this as an example of how a system could define a  
dataset
on named graphs that include tbox internally (by identifying the
named graphs with their implicit closure) without the need for cross- 
graph
inference.

Axel

> > 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 19:42:56 UTC