> 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? 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.
