On 11/05/18 20:35, ajs6f wrote:
On May 9, 2018, at 3:31 AM, Dave Reynolds <[email protected]> wrote:
On 08/05/18 16:55, ajs6f wrote:
Forking a thread off to dev@:
Do we have a global policy about where null is accepted as a wildcard? I know
it works in at least some places...
You have mentioned one place - any others?
I would love to (over an appropriate period of time and with lots of warnings
and deprecation and so forth) stop letting it be a wildcard and require code to
use the actual wildcard objects.
-1
We have a huge amount of code that assumes null-as-wildcard as provided for in
the public RDF API and I doubt we're alone. There would no chance of porting
all that through a normal deprecation cycle.
Fair enough, Dave. Just to be clear, are you saying as much as that new methods
in the public API should always accept null-as-wildcard, or just that we
oughtn't be changing extant methods now?
The public API - Model/Statement/RDFNode - uses null for wildcard.
So does CommonsRDF.
It is an idiom that is understood by users.
In Jena, internally, null in triple pattern and quad pattern API calls
gets converted to Node.ANY.
Triples can not contain nulls. It's enforced.
Quads can only have null in the G slot (which is special - different
discussion), though not S, P or O. It's enforced.
The big pain with nulls is returned values leading to NPEs.
That's not the case here, which is usage for arguments to
functions/methods.
Andy
This overlaps with the debate around Optional as argument.
e.g. first answer to:
Brian Goetz answer:
https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555
and the quote in the second answer.
also
https://stackoverflow.com/questions/31922866/why-should-java-8s-optional-not-be-used-in-arguments
Andy
ajs6f
Dave
On May 8, 2018, at 11:51 AM, Andy Seaborne <[email protected]> wrote:
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.
