Re: empty backup files

[Dan Pritts]

...turns out that the server that I was working on is known to have a 
corrupted index - we'd left it running for no good reason.  Meanwhile, 
development work, and the associated CNAME, had moved on to another 
server.So i was querying the good server's web interface, but 
logging in to the bad server to attempt backups.




I don't know what caused the index to be corrupted on the bad server - 
the person involved is one of those who is unavailable today.  If it 
seems like it might have been errors in fuseki (as opposed to operator 
error) I'll let you know.


For the record, on the bad machine,  the count(*) query returns:

"C": { "type": "literal" , "datatype": 
"http://www.w3.org/2001/XMLSchema#integer; , "value": "0" }


the tdbdump command returns with no output.  So the indices are so 
borked that the code believed there was nothing there.  Which fits with 
a size 0 backup.





Meanwhile, the "working" server, where we have the object we had trouble 
deleting, throws the following error when I try to back it up.  It only 
backs up a couple hundred (out of 20 million) entries before it croaks.


[2018-05-15 16:35:56] Admin  INFO  [156546] 200 OK (12 ms)
[2018-05-15 16:35:56] TDBERROR 
ObjectFileStorage.read[nodes](595777248)[filesize=613223078][file.size()=613223078]: 
Impossibly large object : 1013478516 bytes > 
filesize-(loc+SizeOfInt)=17445826

[2018-05-15 16:35:56] Log4jLoggerAdapter WARN  Exception in backup
org.apache.jena.tdb.base.file.FileException: 
ObjectFileStorage.read[nodes](595777248)[filesize=613223078][file.size()=613223078]: 
Impossibly large object : 1013478516 bytes > 
filesize-(loc+SizeOfInt)=17445826
at 
org.apache.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:348)
at 
org.apache.jena.tdb.base.objectfile.ObjectFileWrapper.read(ObjectFileWrapper.java:57)

at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:78)
at 
org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
at 
org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
at 
org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
at 
org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
at 
org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
at 
org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
at 
org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)



The  configuration is identical - it is a clone made from an AWS snapshot

In case it's useful:

count query:  "C": { "type": "literal" , "datatype": 
"http://www.w3.org/2001/XMLSchema#integer; , "value": "20371945" }


tdbdump dumps what looks like the same few hundred entries, then throws 
a similar stack trace:


17:31:28 ERROR TDB  :: 
ObjectFileStorage.read[nodes](595777248)[filesize=613223078][file.size()=613223078]: 
Impossibly large object : 1013478516 bytes > 
filesize-(loc+SizeOfInt)=17445826
org.apache.jena.tdb.base.file.FileException: 
ObjectFileStorage.read[nodes](595777248)[filesize=613223078][file.size()=613223078]: 
Impossibly large object : 1013478516 bytes > 
filesize-(loc+SizeOfInt)=17445826
at 
org.apache.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:348)

at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:78)
at 
org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
at 
org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
at 
org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
at 
org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)




I  don't know what we did to muck up the indices; again, the appropriate 
guy is unavailable.  I doubt we used anything other than the http sparql 
interface, but i could definitely be wrong.I know he was making very 
significant changes, but i think that was on yet another development 
server.



Andy Seaborne 
May 15, 2018 at 4:42 PM
Dan,

Could you try this query:

SELECT (count(*) AS ?C) { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } }


for the list archives, if anyone ever wants to try this, it's missing a 
trailing }



thanks
danno
--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan

Re: empty backup files

[Andy Seaborne]

Dan,

Could you try this query:

SELECT (count(*) AS ?C) { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } }

and also stop the server and tdbdump --loc 

(Both use mechanism quite similar to how backup is performed.)

Andy

On 15/05/18 19:46, Dan Pritts wrote:

Hi,

I'm attempting to run a backup of a fuseki database. I've done this 
successfully many times on other systems, which I have configured 
identically (AFAIK; it is all done by hand, so an inconsistency is 
possible).


Based on the logs, fuseki appears to run through all the motions, but 
the file that's written is a 20-byte .gz file (i.e., an empty file that 
got gzip'd).  Logs and info below.


I was running 3.6.0 standalone.  I tried upgrading to 3.7.0 standalone, 
which didn't fix it.


Am i doing something wrong, or is this a bug?



In the spirit of full disclosure...I think it's probably fine, but It's 
possible that there is some corruption in the database.


In general queries work fine.   We have one triple with a null value 
that we can't figure out how to delete with sparql.  Our two experts are 
unavailable today and the rest of us are sparql-incompetent.    I don't 
need help with that, we will figure it out when one of them returns 
and/or by reading some more docs.


This led me to the ham-fisted idea of backing up, deleting the offending 
line, and restoring.    I agree with any suggestion that it's a stupid 
solution to this problem - but I still want to be able to back up this 
database, it's inconvenient to recreate it.





database has about 20 million triples.

Java:

log/archonnex/fuseki@acxcore-awstest0% java -version
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-b10)
OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)

fuseki command line:

fuseki 16548  1.1  0.6 12341352   209636 ?    Sl   13:26 
00:00:04 /etc/alternatives/java_sdk_1.8.0/bin/java -Xmx8G 
-Dlog4j.configuration=file:/etc/archonnex/fuseki/log4j.properties 
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps 
-XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100m 
-XX:+PrintTenuringDistribution 
-Xloggc:/var/log/archonnex/fuseki/gc-%t.log -jar 
/usr/local/apache-jena-fuseki-3.7.0/fuseki-server.jar 
--config=/etc/archonnex/fuseki/fcrepo.ttl


ttl config:

# cat fcrepo.ttl
@prefix :   .
@prefix tdb:  .
@prefix rdf:  .
@prefix ja:  .
@prefix rdfs:  .
@prefix fuseki:  .

:service_tdb_all  a fuseki:Service ;
     rdfs:label "TDB fcrepo" ;
     fuseki:dataset :tdb_dataset_readwrite ;
     fuseki:name "fcrepo" ;
     fuseki:serviceQuery "query" , "sparql" ;
     fuseki:serviceReadGraphStore "get" ;
fuseki:serviceReadWriteGraphStore
     "data" ;
     fuseki:serviceUpdate "update" ;
     fuseki:serviceUpload "upload" .

:tdb_dataset_readwrite
     a tdb:DatasetTDB ;
     tdb:location "/var/archonnex/fuseki/data/fcrepo" .


log file:

[2018-05-15 14:18:35] Admin  INFO [1] POST 
http://127.0.0.1:3030/$/backup/fcrepo

[2018-05-15 14:18:35] Admin  INFO [1] Backup dataset /fcrepo
[2018-05-15 14:18:35] Server INFO Task : 1 : backup
[2018-05-15 14:18:35] Server INFO [Task 1] starts : backup
[2018-05-15 14:18:35] Backup INFO [1]  Start backup /fcrepo -> 
/var/archonnex/fuseki/backups/fcrepo_2018-05-15_14-18-35

[2018-05-15 14:18:35] TDB    DEBUG Txn[2]/R: begin$
[2018-05-15 14:18:35] info   DEBUG Triple table: SPO :: SPO,POS,OSP
[2018-05-15 14:18:35] info   DEBUG Quad table: GSPO :: 
GSPO,GPOS,GOSP,POSG,OSPG,SPOG

[2018-05-15 14:18:35] info   DEBUG Prefixes: GPU :: GPU
[2018-05-15 14:18:35] LockMRSW   DEBUG Lock : pool-2-thread-1
[2018-05-15 14:18:35] TDB    DEBUG Txn[2]/R: start
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 >> enterCS: 
Thread R/W: 0/0 :: Model R/W: 0/0 (thread: pool-2-thread-1)
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 << enterCS: 
Thread R/W: 1/0 :: Model R/W: 1/0 (thread: pool-2-thread-1)

[2018-05-15 14:18:35] Admin  INFO [1] 200 OK (8 ms)
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] TDB    DEBUG Txn[2]/R: finish
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 >> leaveCS: 
Thread R/W: 1/0 :: Model R/W: 1/0 (thread: pool-2-thread-1)
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 << leaveCS: 
Thread R/W: 0/0 :: Model R/W: 0/0 (thread: pool-2-thread-1)
[2018-05-15 14:18:35] Backup INFO [1] 

empty backup files

[Dan Pritts]

Hi,

I'm attempting to run a backup of a fuseki database. I've done this 
successfully many times on other systems, which I have configured 
identically (AFAIK; it is all done by hand, so an inconsistency is 
possible).


Based on the logs, fuseki appears to run through all the motions, but 
the file that's written is a 20-byte .gz file (i.e., an empty file that 
got gzip'd).  Logs and info below.


I was running 3.6.0 standalone.  I tried upgrading to 3.7.0 standalone, 
which didn't fix it.


Am i doing something wrong, or is this a bug?



In the spirit of full disclosure...I think it's probably fine, but It's 
possible that there is some corruption in the database.


In general queries work fine.   We have one triple with a null value 
that we can't figure out how to delete with sparql.  Our two experts are 
unavailable today and the rest of us are sparql-incompetent.I don't 
need help with that, we will figure it out when one of them returns 
and/or by reading some more docs.


This led me to the ham-fisted idea of backing up, deleting the offending 
line, and restoring.I agree with any suggestion that it's a stupid 
solution to this problem - but I still want to be able to back up this 
database, it's inconvenient to recreate it.





database has about 20 million triples.

Java:

log/archonnex/fuseki@acxcore-awstest0% java -version
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-b10)
OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)

fuseki command line:

fuseki 16548  1.1  0.6 12341352   209636 ?Sl   13:26 
00:00:04 /etc/alternatives/java_sdk_1.8.0/bin/java -Xmx8G 
-Dlog4j.configuration=file:/etc/archonnex/fuseki/log4j.properties 
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps 
-XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100m 
-XX:+PrintTenuringDistribution 
-Xloggc:/var/log/archonnex/fuseki/gc-%t.log -jar 
/usr/local/apache-jena-fuseki-3.7.0/fuseki-server.jar 
--config=/etc/archonnex/fuseki/fcrepo.ttl


ttl config:

# cat fcrepo.ttl
@prefix :   .
@prefix tdb:  .
@prefix rdf:  .
@prefix ja:  .
@prefix rdfs:  .
@prefix fuseki:  .

:service_tdb_all  a fuseki:Service ;
rdfs:label "TDB fcrepo" ;
fuseki:dataset :tdb_dataset_readwrite ;
fuseki:name "fcrepo" ;
fuseki:serviceQuery "query" , "sparql" ;
fuseki:serviceReadGraphStore "get" ;
fuseki:serviceReadWriteGraphStore
"data" ;
fuseki:serviceUpdate "update" ;
fuseki:serviceUpload "upload" .

:tdb_dataset_readwrite
a tdb:DatasetTDB ;
tdb:location "/var/archonnex/fuseki/data/fcrepo" .


log file:

[2018-05-15 14:18:35] Admin  INFO [1] POST 
http://127.0.0.1:3030/$/backup/fcrepo

[2018-05-15 14:18:35] Admin  INFO [1] Backup dataset /fcrepo
[2018-05-15 14:18:35] Server INFO Task : 1 : backup
[2018-05-15 14:18:35] Server INFO [Task 1] starts : backup
[2018-05-15 14:18:35] Backup INFO [1]  Start backup /fcrepo -> 
/var/archonnex/fuseki/backups/fcrepo_2018-05-15_14-18-35

[2018-05-15 14:18:35] TDBDEBUG Txn[2]/R: begin$
[2018-05-15 14:18:35] info   DEBUG Triple table: SPO :: SPO,POS,OSP
[2018-05-15 14:18:35] info   DEBUG Quad table: GSPO :: 
GSPO,GPOS,GOSP,POSG,OSPG,SPOG

[2018-05-15 14:18:35] info   DEBUG Prefixes: GPU :: GPU
[2018-05-15 14:18:35] LockMRSW   DEBUG Lock : pool-2-thread-1
[2018-05-15 14:18:35] TDBDEBUG Txn[2]/R: start
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 >> enterCS: 
Thread R/W: 0/0 :: Model R/W: 0/0 (thread: pool-2-thread-1)
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 << enterCS: 
Thread R/W: 1/0 :: Model R/W: 1/0 (thread: pool-2-thread-1)

[2018-05-15 14:18:35] Admin  INFO [1] 200 OK (8 ms)
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] BlockAccessMapped DEBUG Segment: 0
[2018-05-15 14:18:35] TDBDEBUG Txn[2]/R: finish
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 >> leaveCS: 
Thread R/W: 1/0 :: Model R/W: 1/0 (thread: pool-2-thread-1)
[2018-05-15 14:18:35] LockMRSW   DEBUG pool-2-thread-1 << leaveCS: 
Thread R/W: 0/0 :: Model R/W: 0/0 (thread: pool-2-thread-1)
[2018-05-15 14:18:35] Backup INFO [1]  Finish backup /fcrepo -> 
/var/archonnex/fuseki/backups/fcrepo_2018-05-15_14-18-35

[2018-05-15 14:18:35] Server INFO [Task 1] finishes : backup

log/archonnex/fuseki@acxcore-awstest0% ls -l 
/var/archonnex/fuseki/backups/fcrepo_2018-05-15_14-18-35*
-rw-rw-r--. 

RE: get derivations via Fuseki

[Nouwt, B. (Barry)]

Hi Andy, thanks for your reply. 

I took a look at the TestFusekiCustomOperation example and it looks quite 
straightforward. I started with a first implementation and the following 
questions arised:

- The Derivation interface does not allow inspecting the derivation via code 
for a particular triple. It only declares a toString() and printTrace() method. 
To be able to generate the derivation log in a JSON or RDF format, this 
interface would probably need to be adapted (or we would need to cast a 
Derivation object to some implementation of this interface making the code less 
reasoner independent).

- The InfGraph interface does not allow checking whether derivation logging is 
enabled. You can only enable/disable it using the above setDerivationLogging() 
method. There is a method in BasicForwardRuleInfGraph.shouldLogDerivations(), 
though. Is there some other way to check whether it is enabled? Or should 
InfGraph get an additional method?

- Since the derivations can take up quite some memory, you need to enable 
derivation logging on an InfGraph using the setDerivationLogging(true) method. 
Can the DerivationService that I'm building call this method on the InfGraph 
when the Fuseki dataset is loaded? Or would it be better to modify the InfGraph 
Assembler code to configure it from a Fuseki configuration file? In that case a 
user would need to remember to enable derivation logging, when it wants to use 
the derivation service.

So, I think some modifications to the Apache Jena source are required to enable 
the derivation service feature.

Regards,

Barry


-Original Message-
From: Andy Seaborne  
Sent: donderdag 10 mei 2018 14:48
To: users@jena.apache.org
Subject: Re: get derivations via Fuseki

Hi Barry,

On 08/05/18 16:53, Nouwt, B. (Barry) wrote:
> Hello everyone,
> 
> I know Apache Jena allows a developer to access the derivation of an inferred 
> triple using the InfModel.getDerivation() method. Can I also access this 
> explanation via Apache Jena Fuseki GUI?
> I have configured Apache Jena Fuseki in such a way that the 
> GenericRuleReasoner infers new triples based on my dataset and a few rules. I 
> am able to fire a SPARQL query via Fuseki GUI and the answer includes the 
> inferred triples as expected. For our project, we would like to access the 
> derivation of an inferred triple via the GUI (as is possible in, for example, 
> Protégé).
> 
> 
>*   Is this already possible in Fuseki? If not;
>*   Would it be interesting if we contribute to Fuseki to add such a 
> feature? And if so;
>*   Are there any relevant pointers to get us started?
> 
> For example, I noticed (in the 3.7.0 release) the following JIRA that sounds 
> like a starting point:
> 
> JENA-1435: Provide extensibility of Fuseki with new services.
> It is now possible to add custom services to a Fuseki service, not 
> just the services provided by the Fuseki distribution.
> 
> Source: 
> https://jena.markmail.org/search/?q=3.7.0#query:3.7.0+page:1+mid:opdcb
> i6qhrim4bsv+state:results
> 
> If it is indeed possible to extend Fuseki with custom services, it might be 
> possible to introduce a new service called 'derivation' that, given a triple, 
> produces the derivation log for that triple. It would produce the explanation 
> in some JSON format. The Apache Jena Fuseki GUI could parse this result and 
> show it on screen.
> 
> So, my first question is: is it already possible to retrieve the derivation 
> log using Apache Jena Fuseki and if so, how?

There isn't such a feature.

> My follow-up question: would it be interesting if we could contribute such a 
> feature to Fuseki?

Yes - and it should be possible to develop such a feature without needing to 
modifying the Fuseki source. That's the point of JENA-1435.

There are some tests in TestFusekiCustomOperation

It is easier to develop functionality using the programmatic, same-JVM form of 
the Fuseki server because the FusekiServer.Builder.

 Andy

> 
> Regards,
> 
> Barry
> 
> This message may contain information that is not intended for you. If you are 
> not the addressee or if this message was sent to you by mistake, you are 
> requested to inform the sender and delete the message. TNO accepts no 
> liability for the content of this e-mail, for the manner in which you use it 
> and for damage of any kind resulting from the risks inherent to the 
> electronic transmission of messages.
> 

RE: parsing and matching triples

[Nouwt, B. (Barry)]

I think that would be a useful addition.

I do not need it anymore, though, since I am basing my solution on your example 
QueryIterator code below. This way I can use variable to represent Node.ANY.

-Original Message-
From: Andy Seaborne  
Sent: dinsdag 15 mei 2018 16:58
To: users@jena.apache.org
Subject: Re: parsing and matching triples

I will add this (for the next release).



On 14/05/18 17:49, Andy Seaborne wrote:
> Hi Barry,
> 
> Sorry, no, there isn't.
> 
> SSE started out for is for SPARQL and SPARQL does not have ANY, it has 
> named variables.
> 
> You can
> 
> SSE.parse("(:s :p ANY)")
> 
> to get back an Item then copy/modify the BuilderGraph/BuilderNode code.
> 
>      Andy
> 
> 
> On 14/05/18 14:08, Nouwt, B. (Barry) wrote:
>> Hi Andy,
>>
>>
>>
>> Regarding the SSE.parseTriple(…) method; how do I parse an ANY Node? 
>> I would expect something like the following exists, but I cannot find 
>> how to do it:
>>
>>
>>
>> SSE.parseTriple(“(test:subj test:pred ANY)”);
>>
>>
>>
>> Regards, Barry
>>
>> Verzonden vanaf mijn Windows 10-telefoon
>>
>> Van: Andy Seaborne
>> Verzonden: maandag 14 mei 2018 13:33
>> Aan: Nouwt, B. (Barry)
>> Onderwerp: Re: parsing and matching triples
>>
>>
>>
>> Barry - could you send questions to the list please?
>>
>> Thanks
>> Andy
>>
>> On 14/05/18 06:50, Nouwt, B. (Barry) wrote:
>>
>> Hi Andy,
>>
>>
>>
>> Regarding the SSE.parseTriple(…) method; how do I parse an ANY Node? 
>> I would expect something like the following exists, but I cannot find 
>> how to do it:
>>
>>
>>
>> SSE.parseTriple(“(test:subj test:pred ANY)”);
>>
>>
>>
>> Regards, Barry
>>
>>
>>
>> Van: Andy Seaborne
>> Verzonden: dinsdag 8 mei 2018 17:51
>> Aan: users@jena.apache.org
>> Onderwerp: Re: parsing and matching triples
>>
>>
>>
>> Barry,
>>
>> As a general concept "matching" happens at different levels.
>>
>> Triple.match corresponds to the matching done by Graph.find - RDF 
>> terms (URI, bnode, literal) match exactly, and Node.ANY is a wildcard.
>>
>> Triple t1 = Triple.ANY;
>> Triple t2 = SSE.parseTriple("(:s :p :o)");
>>    t1.matches(t2) -> true
>>    t2.matches(t1) -> false
>>
>> Variables are a concept for SPARQL - and matches usefully need to 
>> return which variable matched which RDF Term.
>>
>> Triple patterns match against graphs and return an iterator of ways 
>> they match.
>>
>> Consider cases like "?x ?p ?x" where the variables impose am 
>> additional shape.
>>
>> If you want variable bindings, you could build a SPARQL query or wrap 
>> up some of the internal code e.g.
>>
>> /** Evaluate a triple pattern */
>> private static QueryIterator match(Graph source, Triple pattern) {
>>   ExecutionContext execContext =
>>     new ExecutionContext(ARQ.getContext(), source, null, 
>> null) ;
>>   QueryIterator chain = QueryIterRoot.create(execContext)
>>   chain = new QueryIterTriplePattern(chain, pattern, execContext) 
>> ;
>>   return chain ;
>> }
>>
>>   Andy
>>
>> On 08/05/18 09:21, Nouwt, B. (Barry) wrote:
>>> Hi everybody,
>>>
>>> I’m trying to reuse Apache Jena code that parses and matches triples. 
>>> I’m currently looking at the SSE class’s parseTriple() method. This 
>>> seems to fit my purpose for parsing a string representation of a 
>>> triple into a triple object. I also noticed the following Javadoc on 
>>> the Node.maches(Node) method:
>>>
>>> Answer true iff this node accepts the other one as a match.
>>> The default is an equality test; it is over-ridden in subclasses to 
>>> provide the appropriate semantics for literals, ANY, and variables.
>>>
>>> Since this is exactly what I’m looking for, I’ve tried to match two 
>>> triples using the matches() method, but it does not seem to work:
>>>
>>> Triple t1 = SSE.parseTriple("(?s ?p ?o)"); Triple t2 = 
>>> SSE.parseTriple("(test:subject test:predicate test:object)", pm);
>>> t1.matches(t2)
>>>
>>> The final statement returns false, while I would expect it to return 
>>> true. Either, I’m missing something (which is completely realistic
>>> ), or I should use some other method to match two triples in the 
>>> way described above.
>>>
>>> Any help is appreciated!
>>>
>>> Regards, Barry
>>> This message may contain information that is not intended for you. 
>>> If you are not the addressee or if this message was sent to you by 
>>> mistake, you are requested to inform the sender and delete the 
>>> message. TNO accepts no liability for the content of this e-mail, 
>>> for the manner in which you use it and for damage of any kind 
>>> resulting from the risks inherent to the electronic transmission of 
>>> messages.
>>>
>>

Re: parsing and matching triples

[Andy Seaborne]

I will add this (for the next release).



On 14/05/18 17:49, Andy Seaborne wrote:

Hi Barry,

Sorry, no, there isn't.

SSE started out for is for SPARQL and SPARQL does not have ANY, it has 
named variables.


You can

SSE.parse("(:s :p ANY)")

to get back an Item then copy/modify the BuilderGraph/BuilderNode code.

     Andy


On 14/05/18 14:08, Nouwt, B. (Barry) wrote:

Hi Andy,



Regarding the SSE.parseTriple(…) method; how do I parse an ANY Node? I 
would expect something like the following exists, but I cannot find 
how to do it:




SSE.parseTriple(“(test:subj test:pred ANY)”);



Regards, Barry

Verzonden vanaf mijn Windows 10-telefoon

Van: Andy Seaborne
Verzonden: maandag 14 mei 2018 13:33
Aan: Nouwt, B. (Barry)
Onderwerp: Re: parsing and matching triples



Barry - could you send questions to the list please?

Thanks
Andy

On 14/05/18 06:50, Nouwt, B. (Barry) wrote:

Hi Andy,



Regarding the SSE.parseTriple(…) method; how do I parse an ANY Node? I 
would expect something like the following exists, but I cannot find 
how to do it:




SSE.parseTriple(“(test:subj test:pred ANY)”);



Regards, Barry



Van: Andy Seaborne
Verzonden: dinsdag 8 mei 2018 17:51
Aan: users@jena.apache.org
Onderwerp: Re: parsing and matching triples



Barry,

As a general concept "matching" happens at different levels.

Triple.match corresponds to the matching done by Graph.find - RDF terms
(URI, bnode, literal) match exactly, and Node.ANY is a wildcard.

Triple t1 = Triple.ANY;
Triple t2 = SSE.parseTriple("(:s :p :o)");
   t1.matches(t2) -> true
   t2.matches(t1) -> false

Variables are a concept for SPARQL - and matches usefully need to return
which variable matched which RDF Term.

Triple patterns match against graphs and return an iterator of ways they
match.

Consider cases like "?x ?p ?x" where the variables impose am additional
shape.

If you want variable bindings, you could build a SPARQL query or wrap up
some of the internal code e.g.

/** Evaluate a triple pattern */
private static QueryIterator match(Graph source, Triple pattern) {
  ExecutionContext execContext =
    new ExecutionContext(ARQ.getContext(), source, null, null) ;
  QueryIterator chain = QueryIterRoot.create(execContext)
  chain = new QueryIterTriplePattern(chain, pattern, execContext) ;
  return chain ;
}

  Andy

On 08/05/18 09:21, Nouwt, B. (Barry) wrote:

Hi everybody,

I’m trying to reuse Apache Jena code that parses and matches triples. 
I’m currently looking at the SSE class’s parseTriple() method. This 
seems to fit my purpose for parsing a string representation of a 
triple into a triple object. I also noticed the following Javadoc on 
the Node.maches(Node) method:


Answer true iff this node accepts the other one as a match.
The default is an equality test; it is over-ridden in subclasses to
provide the appropriate semantics for literals, ANY, and variables.

Since this is exactly what I’m looking for, I’ve tried to match two 
triples using the matches() method, but it does not seem to work:


Triple t1 = SSE.parseTriple("(?s ?p ?o)");
Triple t2 = SSE.parseTriple("(test:subject test:predicate 
test:object)", pm);

t1.matches(t2)

The final statement returns false, while I would expect it to return 
true. Either, I’m missing something (which is completely realistic 
), or I should use some other method to match two triples in the 
way described above.


Any help is appreciated!

Regards, Barry
This message may contain information that is not intended for you. If 
you are not the addressee or if this message was sent to you by 
mistake, you are requested to inform the sender and delete the 
message. TNO accepts no liability for the content of this e-mail, for 
the manner in which you use it and for damage of any kind resulting 
from the risks inherent to the electronic transmission of messages.