Bei der Gruppe, für die Sie eine Mitteilung verfassen, handelt es sich um eine Usenet-Gruppe. Wenn Sie in dieser Gruppe Nachrichten posten, ist Ihre E-Mail-Adresse für jeden im Internet sichtbar
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".
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?
> 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".
> 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]).
On Feb 8, 8:21 am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
> 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?
On 2010-02-08, William Waites <wwai...@googlemail.com> wrote:
> On Feb 8, 8:21 am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
>> 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 :-(
On Feb 8, 1:57 pm, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
> 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...
On Feb 8, 8:21 am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
> 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.
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...
> On Feb 8, 8:21 am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
>> 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.
> So it turns out that I can't pretend I don't need regex support > in SeRQL since henry's n3 parser uses it.
> 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...
Is this the 5.8.0 binary install for MacOS? Try the latest (5.8.3) or compile from source.
|
