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? Do you have some links for use  
cases on this?
What's the difference/benefit against having separate endpoints (at  
lease from the outside) one supporting simple
and one with RDFS Entailment? 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:

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.


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:02:07 UTC