You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Benson Margulies <bi...@gmail.com> on 2012/01/22 21:37:02 UTC
Is the PathLib thread-safe?
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);
String uri = "urn:com.basistech:subprop";
PathLib.install(uri, path); // this line
Re: Is the PathLib thread-safe?
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Jan 22, 2012 at 5:22 PM, Andy Seaborne <an...@apache.org> wrote:
> On 22/01/12 22:05, Benson Margulies wrote:
>
>>> 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.
>
>
> But rdf:type + properties is unusual.
>
> The object of rdf:type is ... a class.
>
> The subject of rdfs:subPropertyOf is ... a property.
I miswrote above.
I own a family of Jape rules. Each one extracts a relationship.
So, one might produce statements like:
FOO STOLE CAR-27
And another might produce
BAR GOT-A-SALARY-OF 1,000,000
and the various properties (STOLE, GOT-A-SALARY) are arranged in a
little ontology. A *very* little ontology.
It was quite a while ago that I set this up, and I cannot, right this
evening, justify why there is any depth to this. There is the simple
tree of:
SOME-REL-WE-DETECTED
|
-------------------------------------
| |
Literal Not-Literal
| |
GOT-A-SALARY-OF STOLE
but that could just as easily be handled otherwise. I think I might
have been 'planning ahead'. So flattening to remove the need for the
path here is probably trivial. However, I think that I have some more
more interesting path usage elsewhere that I haven't looked at
recently.
>
> Andy
Re: Is the PathLib thread-safe?
Posted by Andy Seaborne <an...@apache.org>.
On 22/01/12 22:05, Benson Margulies wrote:
>> 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.
But rdf:type + properties is unusual.
The object of rdf:type is ... a class.
The subject of rdfs:subPropertyOf is ... a property.
Andy
Re: Is the PathLib thread-safe?
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Jan 22, 2012 at 4:56 PM, Andy Seaborne <an...@apache.org> wrote:
> On 22/01/12 21:42, Benson Margulies wrote:
>>
>> On Sun, Jan 22, 2012 at 4:12 PM, Andy Seaborne<an...@apache.org> 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
>>>
>
Re: Is the PathLib thread-safe?
Posted by Andy Seaborne <an...@apache.org>.
On 22/01/12 21:42, Benson Margulies wrote:
> On Sun, Jan 22, 2012 at 4:12 PM, Andy Seaborne<an...@apache.org> 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
>>
Re: Is the PathLib thread-safe?
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Jan 22, 2012 at 4:12 PM, Andy Seaborne <an...@apache.org> 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);
>
>
> 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.
>
> 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
>
Re: Is the PathLib thread-safe?
Posted by Andy Seaborne <an...@apache.org>.
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);
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)
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