SWI, XPCE, C and Python
William Waites
Not sure if this is really appropriate for the newsgroup, it really
is quite deep in the implementation details of SWI-Prolog. I've got
my version of python bindings for SWI-Prolog working quite well
now, and have an RDFLib store built upon it. It works for basic
values of "work".
Code at http://github.com/wwaites/swipy
Next step: entailment and suchlike
I've pulled in SeRQL and henry, and I find I can't do the equivalent
of load_file(serql(sparql)). It gets angry at the @ characters, and
I found an old post of Jan's saying this has to do with the XPCE
library
not being available.
Now, XPCE (and sparql for that matter) work just fine when running
from the prolog CLI, so it's not a problem with the installation of
SWI-Prolog in general.
Printing out the contents of the library search path, it seems the
embedded version is not finding the paths where XPCE lives. If
I put them in by hand and then try to load one of the files, I get
an error loading the dynamic library, unable to find the symbol
"_environ". Huh? That's supposed to be in the C library...
I'm doing the development on a mac, so otool -L lists the libraries
that things are using, python, prolog and my shared library all link
to a small number of things, the whole X kitchen sink is referred to
by pl2xpce.dylib. So I don't think that passing extra libraries to the
linker for my shared library will help.
I'll try it out on a Linux box tomorrow and see if the behaviour is
the same...
Any ideas or suggestions for how I might be linking the Python module
wrongly?
Cheers,
-w
Jan Wielemaker
> Hi all,
>
> Not sure if this is really appropriate for the newsgroup, it really
> is quite deep in the implementation details of SWI-Prolog. I've got
> my version of python bindings for SWI-Prolog working quite well
> now, and have an RDFLib store built upon it. It works for basic
> values of "work".
>
> Code at http://github.com/wwaites/swipy
>
> Next step: entailment and suchlike
>
> I've pulled in SeRQL and henry, and I find I can't do the equivalent
> of load_file(serql(sparql)). It gets angry at the @ characters, and
> I found an old post of Jan's saying this has to do with the XPCE
> library
> not being available.
The sparql_runtime file uses XPCE's regex handling. If you want that,
you need xpce. For those who don't, I just changed the source not to
use the xpce operators.
If you want to load xpce, you must compile swi('swipl.rc') first.
That is what sets up the binding. The `rc' file loaded is determined
by the name of the executable (or, argv[0]).
--- Jan
William Waites
>
> The sparql_runtime file uses XPCE's regex handling. If you want that,
> you need xpce. For those who don't, I just changed the source not to
> use the xpce operators.
That seems to work. I have yet to try loading XPCE as you suggest
but the problem does seem to be OSX specific - running on a Linux
host gave no errors.
There's also a use of the @ operator in sparql_json_results.pl,
patch below.
I'm going to look into changing the entailment modules to support
rdf/4 in addition to rdf/3. Right now, the RDFLib SWI store works
correctly with named graphs until you turn on inferencing, once
you do that inferencing happens over all triples because of the use
of rdf/3. Does this seem reasonable?
Cheers,
-w
diff --git a/swirdf/SeRQL/sparql_json_result.pl b/swirdf/SeRQL/
sparql_json_result.pl
index bd9d4f0..b09717a 100644
--- a/swirdf/SeRQL/sparql_json_result.pl
+++ b/swirdf/SeRQL/sparql_json_result.pl
@@ -63,7 +63,7 @@ sparql_write_json_result(Out, select(VarNames,
Rows), Options) :-
])).
sparql_write_json_result(Out, ask(True), Options) :-
JSON = json([ head = json([]),
- boolean = @True
+ boolean = @(True)
]),
sparql_json_mime_type(Mime),
with_output_to(Out,
Jan Wielemaker
>>
>> The sparql_runtime file uses XPCE's regex handling. If you want that,
>> you need xpce. For those who don't, I just changed the source not to
>> use the xpce operators.
>
> That seems to work. I have yet to try loading XPCE as you suggest
> but the problem does seem to be OSX specific - running on a Linux
> host gave no errors.
Since a while, we had a lot of trouble generating a binary installer
that realised working X11 bindings. The ones for Snow Leopard are ok.
Since yesterday, the ones for Leopard might be ok as well.
> There's also a use of the @ operator in sparql_json_results.pl,
> patch below.
Thanks. Applied.
> I'm going to look into changing the entailment modules to support
> rdf/4 in addition to rdf/3. Right now, the RDFLib SWI store works
> correctly with named graphs until you turn on inferencing, once
> you do that inferencing happens over all triples because of the use
> of rdf/3. Does this seem reasonable?
Maybe not, but the combination of inreferencing and named graphs is not
very clear. Quite often, the schema information is in graph Y, while the
data is in graph X. Does querying graph X now produce the entailment
that can only be produced using triples from Y? Probably not, but at
least this means we must be able to query a set of graphs.
Graphs were added to the system for source-location administration. That
is useful. Using them in reasoning is a bit more tricky :-( At some
point I was thinking of a dependency(/import) protocol, where you can
specify that graph X imports graph Y. That would make such usage much
more meaningful. Unfortunately, the reasoning is much more complicated.
At the moment, one must already be aware that rdf/4 is merely
post-filtering over the indexed rdf/3 database. Full indexing is quite
feasible over 3 fields, but 4 doubles the indexes :-(
Cheers --- Jan
William Waites
>
> Maybe not, but the combination of inreferencing and named graphs is not
> very clear. Quite often, the schema information is in graph Y, while the
> data is in graph X. Does querying graph X now produce the entailment
> that can only be produced using triples from Y? Probably not, but at
> least this means we must be able to query a set of graphs.
Good point, it's harder than it appears at first. I've developed the
habit from 4store of using named graphs for presentation, that is,
URI dereferencing. Ask the web server for http://example.com/foo and
it looks in the triplestore for a graph called that and returns
whichever triples it finds. This is much nicer (and computationally
much cheaper) than doing searches on the actual triple. Even so,
you are right, I would not normally have schema information in that
graph.
> Graphs were added to the system for source-location administration. That
> is useful.
Which is related to one of the problems that led me to SWI-Prolog in
the first place: attribution and versioning. I suppose arbitrary atoms
and functors can be put in the line part of the graph:line context.
However probably a better place for that is in the transaction
journal,
though to be honest it isn't obvious to me how to query the journal,
how would one effeciently retrieve the log messages and timestamps
pertaining to a particular known triple, for example?
> Using them in reasoning is a bit more tricky :-( At some
> point I was thinking of a dependency(/import) protocol, where you can
> specify that graph X imports graph Y. That would make such usage much
> more meaningful. Unfortunately, the reasoning is much more complicated.
The other use case I had in mind was as a replacement for doing
forward reasoning (using a python package called FuXi) explicitly
by hand for mundane tasks like filling in backlinks. Something
like what you describe here would solve it. The alternative
since there is no index on the graph is to simply nail down the
subject where URIs are being dereferenced...
Or else use it offline to do the forward reasoning as I am doing
now with FuXi only better and more efficiently, basically to fill
out data that goes into 4store for "static" serving...
Cheers,
-w
William Waites
> you need xpce. For those who don't, I just changed the source not to
> use the xpce operators.
So it turns out that I can't pretend I don't need regex support
in SeRQL since henry's n3 parser uses it.
Here's the exact error:
ERROR: /opt/local/lib/swipl-5.8.0/xpce/prolog/boot/pce_principal.pl:
97:
'$open_shared_object'/3: dlopen(/opt/local/lib/swipl-5.8.0/
xpce/lib/i386-darwin9.8.0/pl2xpce.dylib, 1): Symbol not found:
_environ
Referenced from: /opt/local/lib/swipl-5.8.0/xpce/lib/i386-
darwin9.8.0/pl2xpce.dylib
Expected in: flat namespace
Same thing happens if I try to load the unix library from the embedded
prolog. Strange since otool -L unix.dylib shows that it is linked
against libgcc_s...
Cheers,
-w
Jan Wielemaker
Is this the 5.8.0 binary install for MacOS? Try the latest (5.8.3) or
compile from source.
Cheers --- Jan
William Waites
> Is this the 5.8.0 binary install for MacOS? Try the latest (5.8.3) or
> compile from source.
It was the 5.8.0 from macports. I've also tried with 5.8.3 built by
hand,
same thing happens.
Cheers,
-w
Jan Wielemaker
No idea. I guess something must be out-of-date. Wrong version of the
curses libraries? I'd try updating Macports and the Prolog dependencies.
--- Jan