W3C home > Mailing lists > Public > semantic-web@w3.org > May 2008

Re: stating that something doesn't exist

From: Peter Ansell <ansell.peter@gmail.com>
Date: Thu, 22 May 2008 14:13:40 +1000
Message-ID: <a1be7e0e0805212113o2741a6e6j97b574cc6f4487ff@mail.gmail.com>
To: "Johnson, Matthew C. (LNG-HBE)" <Matthew.C.Johnson@lexisnexis.com>
Cc: semantic-web@w3.org

2008/5/22 Johnson, Matthew C. (LNG-HBE) <Matthew.C.Johnson@lexisnexis.com>:
> Hmm.  This is interesting, thanks.  As far as generating a lot of
> triples from a sparsely linking set of publications, I think my actual
> use-case would probably eliminate that.  I suspect that this type of
> query would normally be done on a publication-by-publication basis.  So
> I would really be checking if any links exist specifically for
> publication 2 to [specifically] publication 3.  This would dramatically
> reduce the number of triples generated (although it might still take
> some time).

You can modify this query to specifically insert the two publications
into the query and it should dramatically improve the performance over
the all vs all publication because it is still an existence query so
if the SPARQL engine can utilise a database index against specific
publications it should have similar performance to a direct SQL query.

> Also, I suspect another alternative would be to let the application
> itself do some of the rationalization by simply grabbing all of the
> publications that "pub 2" does link to (a simple query) and then
> checking to see if "pub 3" is in that list.  Ideally, I would like the
> data or query to say this directly (really, I'd just like a yes or no
> answer) but if performance becomes an issue, it might be a second
> choice.

I don't think the query would be too inefficient if you know what the
publications are. I was referring to the all vs all capabilities when
I said it might not be efficient. Basically if there is a row returned
then you have a result, or conversely if no rows are returned then you
have the opposite result.

Received on Thursday, 22 May 2008 04:14:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:04 UTC