On 22/01/12 21:42, Benson Margulies wrote:
On Sun, Jan 22, 2012 at 4:12 PM, Andy Seaborne<[email protected]> wrote:
On 22/01/12 20:37, Benson Margulies wrote:
The code below cribbed from the web site has a certain 'static'
feeling to it. Do I have to worry about threads, or is dealt with
internally?
Path path = PathParser.parse("rdf:type/rdfs:subPropertyOf+",
PrefixMapping.Standard);
Do you really mean subPropertyOf and not subClassof?
The twoidoms are:
?s rdf:type ?t .
?t rdfs:subClassOf* :T
or ?s rdf:type/rdfs:subClassOf* :T .
and
?s ?p ?o .
?p rdfs:subPropertyOf* :P .
Calls the parser. It creates the parser internally - the static just wraps
up the outer code to drive the process and it uses function local variables.
Path objects are just datastructures to be walked in execution.
String uri = "urn:com.basistech:subprop";
PathLib.install(uri, path); // this line
This is all setup code. It should be done once as a matter of style (the
internal registry is MRSW - this is W)
As a temporary measure while I fiddle with virtuoso, I was tempted to
put these at the point where I run into the problems, and then decide
how to neaten it up later.
Will it help?
Property functions are an engine-ism that is triggered during execution.
Specifically, in ARQ, translating syntax to algebra causes a property
function algebra operator to be injected into the algebra.
But Virtuoso takes the whole SPARQL query string and does its thing
without reference to ARQ. A property function will just be a plain
property to Virtuoso.
If you are able to preprocess the data and change queries a little:
Expand the class hierarchy so all types are directly connected to all
their super classes by an explicit rdfs:subClassOf -- maybe store in a
separate graph.
?s rdf:type/rdfs:subClassOf+ :T .
becomes:
?s rdf:type ?t .
GRAPH ... { ?t rdfs:subClassOf :T }
Andy
The registry adds something that creates one-time-use instances for
execution. The code does all this before the multiple parallel queries
which can be multiple-reader.
Andy
