Re: SPARQL query

Osma, I think I am asking for the latter. Table wise it looks like this {noformat} A B C D Match w1 1 No x1 1 1 Yes y1 1 Yes z1 1 1 1 No Looking for matches for P1 1 1

Re: SPARQL query

Hi Claude, Do you mean something like this? SELECT ?r WHERE { { # must have at least one of A, B, C { ?r :p :A } UNION { ?r :p :B } UNION { ?r :p :B } } # must not have D, E or F FILTER NOT EXISTS { ?r :p :D } FILTER NOT EXISTS { ?r :p :E } FILTER NOT EXISTS { ?r

Re: SPARQL query

Hi All, Here is what Claude's example looks like in executable English. *some-resource has the property some-propertynot : that-resource has a non-matching property--that-resource having that-property

Re: SPARQL query

Maybe something like: Select ?s ?p ?o Where { ?s ?p ?o. Filter (?p in (:A, :B, :C)) Minus {?s ?p2 ?o2. Filter (!(?p2 in (:A, :B, :C)))} Untested. Regards, --Paul > On Mar 1, 2017, at 14:12, Claude Warren wrote: > > I have a graph where resources have a number of controlled

Re: SPARQL query

I believe you need to AND together the NOT EXISTS of D, E, and F in a filter. https://www.w3.org/TR/sparql11-query/#neg-notexists On 1/3/17, 15:12, "Claude Warren" wrote: >I have a graph where resources have a number of controlled properties. >Call them A thorough F. Some

SPARQL query

I have a graph where resources have a number of controlled properties. Call them A thorough F. Some resources may have one property other may have all 6. I have a resource with a with properties A, B, and C. I want to find all resources in the graph where the resource has matching values but

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

Thanks Osma. I sent my previous email just a minute early. I will try your suggestion and if it doesn't work will send you the entire example. Thanks again. Anuj On 1 Mar 2017 19:36, "Osma Suominen" wrote: > Hi Anuj! > > Generally I use assembler descriptions to

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

I agree Osma. If Lucent is upgraded to 6.4.1 it would be much easier for me to integrate the Elastic Search implementation. But I am still waiting for someone to provide me a hint as to how I can index multiple predicate values. This is the most pressing issue for me currently. Thanks, Anuj

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

Hi Anuj! Generally I use assembler descriptions to configure the jena-text index. An example with multiple properties (SKOS label properties) is here: https://github.com/NatLibFi/Skosmos/wiki/InstallTutorial#creating-a-text-index For examples on how to use assembler descriptions from Java

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

Hi Anuj! I have nothing against modularity in general. However, I cannot see how your proposal could work in practice for the Fuseki build, due to the reasons I mentioned in my previous message (and Adam seemed to concur). In any case, I'll see what I can do to get the Lucene upgrade moving

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

> On Feb 28, 2017, at 11:23 AM, Osma Suominen wrote: > 28.02.2017, 17:12, A. Soroka kirjoitti: >> https://lists.apache.org/thread.html/dce0d502b11891c28e57bbcbb0cdef27d8374d58d9634076b8ef4cd7@1431107516@%3Cdev.jena.apache.org%3E >> ? In other words, might it be better

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

BTW, I have one more question: How do I add more than one field to be indexed in my Index? Basically, if I want to index rdfs:label , rdfs:comment in the same index document, how do I do it? I tried : EntityDefinition entDef = new EntityDefinition(DOC_TYPE, FIELD_TO_SEARCH);

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

I personally have no preference as to how the code in Jena should be structured, as long as I am able to use it :). I have personal preference of doing it in a specific way because IMO, it is modular which makes it much easier to maintain in the long run. But again it may not be the quickest one.

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

Osma-- The short answer is that yes, given the right tools you _can_ have different versions of code accessible in different ways. The longer answer is that it's probably not a viable alternative for Jena for this problem, at least not without a lot of other change. You are right to point to

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

Hi Anuj! Thanks for the clarification. However, I'm still not sure I understand the situation completely. I know Maven can perform a lot of tricks, but Maven modules are just convenient ways to structure a Java project. Maven cannot change the fact that at runtime, module divisions don't

Re: QueryParseException: java.lang.StackOverflowError

Thank you for your help. I'll try the ARQ parser. Sincerely, Laurent On 22 February 2017 at 17:12, Andy Seaborne wrote: > Now that standards are settled, we could consider making SPARQL 1.1 have > this change. It is not a language change, it is only a grammar change >

Re: Deleting the default graph from the TDB

Thank you very much, that was the problem. I did not change so far this default setting in the config file: <#dataset> rdf:type tdb:DatasetTDB ; tdb:location "/var/www/fuseki/tdb" ; tdb:unionDefaultGraph true ; I set it now to false (or better commented out), and now the DROP

Re: ResultSetFormatter outputs illegal XML

Rick, The data needs to be cleaned or treated as XML 1.1. XML 1.0 does not have way to encode or escape such a character. There is no way to write the results legally in XML 1.0. XML 1.1 does allow it. See XML rule [2], the only characters allowed in an XML document. Rule [66] requires

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

Hi Osma, I understand what you are saying. There are ways to mitigate risks and balance the refactoring without affecting the existing modules. But I will not delve into those now. I am not an expert in Jena to convincingly say that it is possible, without any hiccups. But I can take a guess and