- From: Frank Carvalho <dko4342@vip.cybercity.dk>
- Date: Sat, 24 Nov 2007 07:04:12 -0800 (PST)
- To: semantic-web@w3.org
>If I got your point, you want ways to hop from a node to another node in the >proximity, say A is your node, you want node B such that: >A someproperty B Yes, that's my standard test case, though I also need those nodes where C someproperty A. That is, the immediate vicinity of A - both forward and backward. >In this case it may be faster to use the Jena API instead of SPARQL: once >you get A in some way, you call A.listProperties() to have all statements >with A as subject (including those referring to B). More specialized >requests, such as list the properties with a specific predicate, are easy as >well. We did actually do this using the API, and it is vastly faster, so for the graphical exploration of the graph we would certainly use that approach in any case. I also suspect that the API is really the only way to make forward and backward chaining efficiently. My concern is really more if the SPARQL language is nice, but inefficient for practical purposes. You see, when the graph is a way to describe the artifacts for a SOA, and we want to enable the business to make intelligent analysis of the impact of changes, we need to be able to tailor make requests for each purpose. So we need a language like SPARQL to do that in a flexible way. So it is a serious problem if the language - or the implementation of the query engine - is inherently slow. /Frank -- View this message in context: http://www.nabble.com/Introducing-myself---SOA-organised-with-RDF-tf4263503.html#a13925369 Sent from the w3.org - semantic-web mailing list archive at Nabble.com.
Received on Saturday, 24 November 2007 15:04:22 UTC