Re: Signalling entailment in queries

On Tue, Jul 20, 2010 at 5:37 PM, Sandro Hawke <> wrote:
> I want to make sure the graph-data world sees inference as something
> useful and not as something unknown, unpredictable, and to be avoided.
> I think the KR folks know that SPARQL doesn't really support them in a
> standard way yet, so they can be a lot more flexible.   Of course I
> don't want to cause any unnecessary hassles for anyone, etc, too.

I don't think this distinction is that useful (KR, plain SPARQL); but
since we have customers & apps in both spaces, I'll say that this
'signal inference' thing is not a problem in practice. At least, we
haven't ever encountered it in 5+ years.

If the SD says 'no inference' at 5pm and you turn on inference at 6pm,
then update the SD at 5:59pm. Seriously, this would just *never*
happen in practice in my experience. Changing how the system works in
this way is a configuration management issue & would be handled as
such (i.e., an entry in a changelog for the new version, a blog post
on the SaaS blog explaining the new version, etc).

Of course, our experience is not universal, but I suggest that this is
more of a corner than a core use case and we shouldn't do very much,
if anything, at this relatively late date about this issue.

Just update the SD before you change the service that it describes.
Easy to do, simple to explain, good enough. :>

Our two cents and probably worth at least 1 cent at this point. :>


PS--I don't believe it's true that "KR folks know that SPARQL doesn't
really support them in a standard way yet"... Most users and customers
don't really make that fine-grained distinctions between SPARQL as
specified in 1.0 (where there wasn't really any entailment stuff per
se) and SPARQL as implemented by their preferred vendor, where there
may be all manner of extensions, including inference (and a bunch of
other stuff: spatial, temporal, graph analysis, social network,
probabilistic, etc etc).

Received on Tuesday, 20 July 2010 21:46:32 UTC