On Sun, Jan 22, 2012 at 4:56 PM, Andy Seaborne <[email protected]> wrote:
> 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 .
I happen to have a little tree of properties. These are named entity
types. I thought I wanted + because a zero-length path of them means
'not one of these.' I've been running this for a very long time
successfully.
>
>
>>>
>>>
>>> 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?
I understand your explanation below. Without it, Virtuoso complained
bitterly that the syntax was wrong. With it, no more complaints ---
but the Virtuoso server died with a sigsegv due to a feud with
pthreads on MacOSX. Coincidence? I am beginning to lose enthusiasm for
this whole exercise. And, as per the explanation, nothing good
happens. So I really need to rewrite the sparql or restructure the
data so that I don't need the path. Or rewrite their driver :-). or
try your graph proposal from earlier on.
>
> 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
>>>
>
