On 12/05/18 17:26, Dave Reynolds wrote:
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...
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 latter. I've no particular attachment to null-as-wildcard as a
design pattern so new APIs (at least ones which aren't just tweaks on
the existing API) could go a different route.
I'm against having a mixed design in one API (e.g. new methods on Graph,
or elsewhere in related classes/interfaces). Design uniformity matters
and the current SPI is what it is.
I believe that new API work should be matured separately. There is scope
for more modern design, although with the existence of Commons RDF, it
needs to find it's own rational and community.
Andy
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.
