- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Thu, 22 May 2008 14:13:40 +1000
- 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. Peter
Received on Thursday, 22 May 2008 04:14:17 UTC