W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

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

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sat, 17 Oct 2009 15:43:44 +0000
To: Axel Polleres <axel.polleres@deri.org>
CC: Birte Glimm <birte.glimm@comlab.ox.ac.uk>, Ivan Herman <ivan@w3.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693FA224DC@GVW1118EXC.americas.hpqcorp.net>


> -----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 15:44:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT