[jira] [Resolved] (RYA-417) Implement a forward-chaining rules engine (SPIN)
[ https://issues.apache.org/jira/browse/RYA-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-417. - Resolution: Fixed > Implement a forward-chaining rules engine (SPIN) > > > Key: RYA-417 > URL: https://issues.apache.org/jira/browse/RYA-417 > Project: Rya > Issue Type: New Feature >Reporter: Jesse Hatfield >Assignee: Jesse Hatfield >Priority: Major > Fix For: 3.2.12 > > > Implement a forward-chaining reasoner that: > * Runs as a batch process > * Operates on user-defined [SPIN|http://spinrdf.org] rules > * Inserts derived information back into Rya > * Iterates until no new information can be derived -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RYA-416) Add the ability use the MongoDB aggregation pipeline to evaluate simple SPARQL expressions
[ https://issues.apache.org/jira/browse/RYA-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-416. - Resolution: Fixed > Add the ability use the MongoDB aggregation pipeline to evaluate simple > SPARQL expressions > -- > > Key: RYA-416 > URL: https://issues.apache.org/jira/browse/RYA-416 > Project: Rya > Issue Type: New Feature >Reporter: Jesse Hatfield >Assignee: Jesse Hatfield >Priority: Major > Fix For: 3.2.12 > > > MongoDB provides the [aggregation pipeline > framework|https://docs.mongodb.com/manual/core/aggregation-pipeline/] for > multi-stage data processing. Currently, the query engine invokes this > framework to apply individual statement patterns (using a "$match" expression > for each and iterating through the results), then applies higher-level query > operations (join, filter, select, project, etc) client-side. > In principle, those high-level query operations could be rewritten as > aggregation pipeline stages as well ($group, $match, $project, etc). This > would allow more query evaluation logic to be executed by the MongoDB server > itself, enabling server-side optimization. This could be used as a general > query optimization, but would additionally be useful for any tool that only > needed to write query results back to the server: adding a write step to the > end of the resulting pipeline could obviate the need to communicate > individual results to the client at all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RYA-430) Lazily Instantiate RyaSubGraphExporter
Caleb Meier created RYA-430: --- Summary: Lazily Instantiate RyaSubGraphExporter Key: RYA-430 URL: https://issues.apache.org/jira/browse/RYA-430 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.12 Reporter: Caleb Meier Assignee: Caleb Meier The RyaSubgraphExporter requires a FluoClient when it is constructed. Unfortunately, the RyaSubGraphExporter factory creates the exporter when the QueryResultObserver is being initialized. This is problematic in that if the observer is not initialized, then Fluo has not been initialized and a FluoClient cannot be created. Instead, the RyaSubgraphExporter should be constructed using a FluoClient supplier that takes in the necessary configuration and lazily supplies and memoizes a FluoClient the first time the export method is invoked. Additionally, as it is currently implemented, the RyaSubGraphExporter generates a Transaction within a Transaction which can lead to Exceptions being thrown if for some reason the outer transaction completes before the inner transaction. Given how the Exporter interface is currently laid out, the exporter does not currently accept a transaction (nor should it). Therefore, perhaps the RyaSubgraphExporter should be done away with altogether given that it merely inserts triples back into Fluo and is a placeholder for an Exporter that inserts triples back into Rya itself (once we resolve packaging issues to support full indexing). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-408) PCJ Updater Does Not Support Queries with DIrect Products
[ https://issues.apache.org/jira/browse/RYA-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-408: Description: A number of optimizations were made to the Rya PCJ Updater to support sharding. Among these optimizations was sharding the binding set results to distribute the load among the tablet servers. These changes prevent the JoinResultUpdater from creating joins that are the result of direct products. This is a result of how new rows are written in the Fluo table. For example, statement patterns used to be written in the form "SP_123/BS_Val1:BS_Val2", but are now written as SP:HASH(BS_Val1):123/BS_Val1:BS_Val2", where HASH(BS_Val1) is the hash of the first binding set value. Before sharding, a targeted range scan for all the results associated with SP_123 could be done, because all of entries associated with that node had that prefix. After sharding, it is impossible to do a targeted range lookup on values corresponding to SP_123 without the first binding set value (because the hash precedes the id = 123). So if the JoinResultUpdater attempts to join a new StatementPattern result with the results of another StatementPattern and there are no common variables (and therefore no first binding value to hash), then the updater will not locate any results. This issue can be resolved by issuing a more general scan on the "SP" prefix and then filtering the results on the StatementPattern nodeId (123 in the above example). This is not a very performant approach, but may be the only way to resolve the issue. Given the large amount of data that is currently stored in the Fluo table already, there is some question about whether we should support direct products in Fluo queries anyway. Another approach is to simply attempt to optimize queries to avoid direct queries when they are registered (this should be done anyway), and if there is no arrangement that avoid direct products, then throw an exception. So we could take the approach that queries that have unavoidable direct products should not be allowed to be registered in Fluo. was: A number of optimizations were made to the Rya PCJ Updater to support sharding. Among these optimizations was sharding the binding set results to distribute the load among the tablet servers. The changes that were made to shard the rows prevents the JoinResultUpdater from creating joins that are the result of direct products. This is a direct result of how new rows are written in the Fluo table. For example, statement patterns used to be written in the form "SP_123/BS_Val1:BS_Val2", but are now written as SP:HASH(BS_Val1):123/BS_Val1:BS_Val2", where HASH(BS_Val1) is the hash of the first binding set value. After sharding, it is impossible to do a targeted range lookup on values corresponding to SP_123 without the first binding set value (because the hash precedes the id). So if the JoinResultUpdater attempts to join a new StatementPattern result with the results of another StatementPattern and there are no common variables (and therefore no first binding value to hash), then the updater will not locate any results. This issue can be resolved by issuing a more general scan on the "SP" prefix and then filtering the results on the StatementPattern nodeId. This is not a very performant approach, but may be the only way to resolve the issue. Given the large amount of data that is currently stored in the Fluo table already, there is some question about whether we should support direct products in Fluo queries anyway. Another approach is to simply attempt to optimize queries to avoid direct queries when they are register (this should be done anyway), and if there is no arrangement that avoid direct products, then throw an exception. Queries that have unavoidable direct products should not be allowed to be registered in Fluo. > PCJ Updater Does Not Support Queries with DIrect Products > - > > Key: RYA-408 > URL: https://issues.apache.org/jira/browse/RYA-408 > Project: Rya > Issue Type: Bug > Components: clients >Affects Versions: 3.2.12 >Reporter: Caleb Meier > > A number of optimizations were made to the Rya PCJ Updater to support > sharding. Among these optimizations was sharding the binding set results to > distribute the load among the tablet servers. These changes prevent the > JoinResultUpdater from creating joins that are the result of direct products. > This is a result of how new rows are written in the Fluo table. For > example, statement patterns used to be written in the form > "SP_123/BS_Val1:BS_Val2", but are now written as > SP:HASH(BS_Val1):123/BS_Val1:BS_Val2", > where HASH(BS_Val1) is the hash of the first binding set value. Before > sharding, a targeted range sc
[jira] [Created] (RYA-408) PCJ Updater Does Not Support Queries with DIrect Products
Caleb Meier created RYA-408: --- Summary: PCJ Updater Does Not Support Queries with DIrect Products Key: RYA-408 URL: https://issues.apache.org/jira/browse/RYA-408 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.12 Reporter: Caleb Meier A number of optimizations were made to the Rya PCJ Updater to support sharding. Among these optimizations was sharding the binding set results to distribute the load among the tablet servers. The changes that were made to shard the rows prevents the JoinResultUpdater from creating joins that are the result of direct products. This is a direct result of how new rows are written in the Fluo table. For example, statement patterns used to be written in the form "SP_123/BS_Val1:BS_Val2", but are now written as SP:HASH(BS_Val1):123/BS_Val1:BS_Val2", where HASH(BS_Val1) is the hash of the first binding set value. After sharding, it is impossible to do a targeted range lookup on values corresponding to SP_123 without the first binding set value (because the hash precedes the id). So if the JoinResultUpdater attempts to join a new StatementPattern result with the results of another StatementPattern and there are no common variables (and therefore no first binding value to hash), then the updater will not locate any results. This issue can be resolved by issuing a more general scan on the "SP" prefix and then filtering the results on the StatementPattern nodeId. This is not a very performant approach, but may be the only way to resolve the issue. Given the large amount of data that is currently stored in the Fluo table already, there is some question about whether we should support direct products in Fluo queries anyway. Another approach is to simply attempt to optimize queries to avoid direct queries when they are register (this should be done anyway), and if there is no arrangement that avoid direct products, then throw an exception. Queries that have unavoidable direct products should not be allowed to be registered in Fluo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-406) Sharding for Fluo Application
Caleb Meier created RYA-406: --- Summary: Sharding for Fluo Application Key: RYA-406 URL: https://issues.apache.org/jira/browse/RYA-406 Project: Rya Issue Type: Improvement Affects Versions: 3.2.12 Reporter: Caleb Meier Assignee: Caleb Meier The Rya Fluo Application overwhelms the Accumulo Tablet servers with scans in part because of a high scan rate, but also because scans are not being evenly distributed among Tablet Servers. All binding sets should be sharded so that scans can be evenly distributed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-400) Consolidate MongoTestBase and MongoRyaTestBase
[ https://issues.apache.org/jira/browse/RYA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-400: Description: MongoITBase exists in the geo project. This class could probably be deleted if MongoTestBase is migrated to a test project. In addition, it appears the MongoRyaTestBase is not using the MongoSingleton. It should be deleted and replaced by MongoTestBase. > Consolidate MongoTestBase and MongoRyaTestBase > -- > > Key: RYA-400 > URL: https://issues.apache.org/jira/browse/RYA-400 > Project: Rya > Issue Type: Sub-task > Components: build >Reporter: Caleb Meier > Fix For: 3.2.12 > > > MongoITBase exists in the geo project. This class could probably be deleted > if MongoTestBase is migrated to a test project. In addition, it appears the > MongoRyaTestBase is not using the MongoSingleton. It should be deleted and > replaced by MongoTestBase. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-400) Consolidate MongoTestBase and MongoRyaTestBase
Caleb Meier created RYA-400: --- Summary: Consolidate MongoTestBase and MongoRyaTestBase Key: RYA-400 URL: https://issues.apache.org/jira/browse/RYA-400 Project: Rya Issue Type: Sub-task Reporter: Caleb Meier Fix For: 3.2.12 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-392) Temporal Difference Function
[ https://issues.apache.org/jira/browse/RYA-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-392: Description: Currently Rya does not provide a Function that determines whether two temporal literals are within a given period of time of one another. This is extremely useful for filtering on query results that occurred within a fixed period of time of a given instant. Currently, if one attempts to form the following filter Filter(?time1 - ?time2 < "24"^^xsd:hour), an exception will be thrown if ?time1 and ?time2 are date time literals. I propose implementing a Function that takes in two temporal literals, an integer and a time unit and determines whether the date times are within the prescribed period of one another. (was: Currently Rya does not provide a Function that determines whether two temporal literals are within a given period of time one one another. This is extremely useful for filtering on query results that occurred within a fixed period of time of a given instant. Currently, if one attempts to form the following filter Filter(?time1 - ?time2 < "24"^^xsd:hour), an exception will be thrown if ?time1 and ?time2 are date time literals. I propose implementing a Function that takes in two temporal literals an integer and a time unit and determines whether the date times are within the prescribed period of one another.) > Temporal Difference Function > > > Key: RYA-392 > URL: https://issues.apache.org/jira/browse/RYA-392 > Project: Rya > Issue Type: New Feature >Affects Versions: 3.2.11 >Reporter: Caleb Meier >Assignee: Caleb Meier > > Currently Rya does not provide a Function that determines whether two > temporal literals are within a given period of time of one another. This is > extremely useful for filtering on query results that occurred within a fixed > period of time of a given instant. Currently, if one attempts to form the > following filter Filter(?time1 - ?time2 < "24"^^xsd:hour), an exception will > be thrown if ?time1 and ?time2 are date time literals. I propose > implementing a Function that takes in two temporal literals, an integer and a > time unit and determines whether the date times are within the prescribed > period of one another. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-392) Temporal Difference Function
Caleb Meier created RYA-392: --- Summary: Temporal Difference Function Key: RYA-392 URL: https://issues.apache.org/jira/browse/RYA-392 Project: Rya Issue Type: New Feature Affects Versions: 3.2.11 Reporter: Caleb Meier Assignee: Caleb Meier Currently Rya does not provide a Function that determines whether two temporal literals are within a given period of time one one another. This is extremely useful for filtering on query results that occurred within a fixed period of time of a given instant. Currently, if one attempts to form the following filter Filter(?time1 - ?time2 < "24"^^xsd:hour), an exception will be thrown if ?time1 and ?time2 are date time literals. I propose implementing a Function that takes in two temporal literals an integer and a time unit and determines whether the date times are within the prescribed period of one another. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-374) Aggregation Result Join Bug
Caleb Meier created RYA-374:
---
Summary: Aggregation Result Join Bug
Key: RYA-374
URL: https://issues.apache.org/jira/browse/RYA-374
Project: Rya
Issue Type: Bug
Components: clients
Affects Versions: 3.2.11
Reporter: Caleb Meier
Assignee: Caleb Meier
Right now, it is not possible to join on aggregation results that come from
nested queries within the Rya Trigger Service. For example, in the following
query
select ?msg ?lastObserved where {
{select (MAX(?time) AS ?lastObserved) {
?msg ?time
}}
?msg ?lastObserved
}
would not return the msg with the last observed time. It returns all messages,
paired with
the last returned time. So it does not join on the last observed time. This
is because of how aggregation results are handled in the trigger service. The
values are stored in the value field of the key, as opposed to the row. When a
join is performed, the Fluo table is scanned using a prefix over the contents
of its rows. Therefore, the aggregation result is not taken into account.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-296) Implement owl:hasSelf inference
[
https://issues.apache.org/jira/browse/RYA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-296.
---
> Implement owl:hasSelf inference
> ---
>
> Key: RYA-296
> URL: https://issues.apache.org/jira/browse/RYA-296
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Reporter: Jesse Hatfield
>Assignee: Andrew Smith
>
> An *{{owl:hasSelf}}* restriction defines the set of resources that are
> connected to themselves by a specific property.
> If the ontology states that a {{:Narcissist}} is a resource that {{:loves}}
> itself, then the inference engine should:
> 1. Rewrite queries of the form {{?x rdf:type :Narcissist}} to find all
> resources matching {{?x :loves ?x}} (as well as anything explicitly stated to
> be a :Narcissist) .
> 2. Rewrite queries of either form {{:A :loves ?y}} or {{?z :loves :A}} to
> match {{:A}} if {{:A}} is known to have the type {{:Narcissist}} .
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-332) Rename IntegrationTests to be suffixed with IT so they are tested.
[
https://issues.apache.org/jira/browse/RYA-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-332.
---
> Rename IntegrationTests to be suffixed with IT so they are tested.
> --
>
> Key: RYA-332
> URL: https://issues.apache.org/jira/browse/RYA-332
> Project: Rya
> Issue Type: Sub-task
> Components: build
>Reporter: Jeff Dasch
>Assignee: Andrew Smith
>
> Several Integration Tests do not get tested by the maven-failsafe-plugin
> because they do not follow the standard IT naming convention (*IT.java).
> Also, remove the maven-surefire-plugin *IntegrationTest.java exclusion in the
> parent pom.
> Affected tests:
> {noformat}
> $ find incubator-rya -name *IntegrationTest.java
> incubator-rya/extras/indexing/src/test/java/org/apache/rya/indexing/external/AccumuloConstantPcjIntegrationTest.java
> incubator-rya/extras/indexing/src/test/java/org/apache/rya/indexing/external/AccumuloPcjIntegrationTest.java
> incubator-rya/extras/indexing/src/test/java/org/apache/rya/indexing/external/PrecompJoinOptimizerIntegrationTest.java
> incubator-rya/extras/rya.indexing.pcj/src/test/java/org/apache/rya/indexing/pcj/storage/accumulo/PcjTablesIntegrationTest.java
> incubator-rya/osgi/camel.rya/src/test/java/org/apache/rya/camel/cbsail/CbSailIntegrationTest.java
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-289) During tests, Mock Mongo instances are being left open
[ https://issues.apache.org/jira/browse/RYA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-289. --- > During tests, Mock Mongo instances are being left open > -- > > Key: RYA-289 > URL: https://issues.apache.org/jira/browse/RYA-289 > Project: Rya > Issue Type: Bug >Reporter: Andrew Smith >Assignee: Andrew Smith >Priority: Minor > > Looking at the logs, it would appear a bunch of mongo clients are being left > open after using the MockMongoFactory -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-351) Create test jar containing MongoTestBase
Caleb Meier created RYA-351: --- Summary: Create test jar containing MongoTestBase Key: RYA-351 URL: https://issues.apache.org/jira/browse/RYA-351 Project: Rya Issue Type: Improvement Affects Versions: 3.2.11 Reporter: Caleb Meier A test jar containing MongoTestBase needs to be created so that it can be used across projects. Once this is created, there are a number of extraneous classes that can be deleted (such as Mongo base testing classes in the geoindexing project). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-292) Implement owl:intersectionOf inference
[
https://issues.apache.org/jira/browse/RYA-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-292.
---
Resolution: Fixed
Fix Version/s: 3.2.11
> Implement owl:intersectionOf inference
> --
>
> Key: RYA-292
> URL: https://issues.apache.org/jira/browse/RYA-292
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Reporter: Jesse Hatfield
>Assignee: Eric White
> Fix For: 3.2.11
>
>
> An *{{owl:intersectionOf}}* expression defines the set of resources who
> belong to all of a particular set of classes.
> A basic implementation, if the ontology states that {{:Mother}} is the
> intersection of {{:Parent}} and {{:Woman}}, should cause the inference engine
> to:
> 1. Rewrite query patterns {{?x rdf:type :Mother}} (the intersection type) to
> check for resources that have both types {{:Parent}} and {{:Woman}} (as well
> as check for resources that are explicitly stated to be {{:Mother}} s)
> 2. Rewrite query patterns {{?y rdf:type :Parent}} (one of the intersecting
> sets) to check for resources that are stated to be either {{:Mother}} or
> {{:Parent}} , since belonging to the intersection type implies membership in
> the component types. (Equivalent logic applies to {{Woman}} )
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-281) Decouple PCJ Creation in RYA and Fluo
[ https://issues.apache.org/jira/browse/RYA-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-281. --- Resolution: Fixed Fix Version/s: 3.2.11 > Decouple PCJ Creation in RYA and Fluo > - > > Key: RYA-281 > URL: https://issues.apache.org/jira/browse/RYA-281 > Project: Rya > Issue Type: Bug > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.11 > > > Currently PCJ creation in RYA and FLUO are coupled together. That is, PCJ > creation within RYA is currently a prerequisite for creating a PCJ in Fluo > (you need to pass in a PCJ ID when creating the Fluo metadata, and that ID is > used to read information about the RYA PCJ from RyaDetails). In the past > this was fine, but now we would like to be able to register a query with Fluo > whose results are not necessarily being exported to a PCJ table. Another > issue is that the RYA PCJ ID and the Fluo query ID don't align, which > requires us to store the PCJ ID in the Fluo table so that the RYA Exporter > can write results to the RYA PCJ table. These two IDs should be the same. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-246) Separate Fluo query result exporters, Rya PCJ intermingled kafka triggers
[
https://issues.apache.org/jira/browse/RYA-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-246.
---
Resolution: Fixed
Fix Version/s: 3.2.11
> Separate Fluo query result exporters, Rya PCJ intermingled kafka triggers
> -
>
> Key: RYA-246
> URL: https://issues.apache.org/jira/browse/RYA-246
> Project: Rya
> Issue Type: Improvement
> Components: dao
> Environment: Fluo, Kafka, PCJ, Accumulo
>Reporter: David W. Lotts
>Assignee: Caleb Meier
> Fix For: 3.2.11
>
>
> Currently the Fluo query observer framework (FQF) has a great plugin-in-ish
> way of doing exports. (See field: {{exporters}} in class:
> {{org.apache.rya.indexing.pcj.fluo.app.observers.QueryResultObserver}} )
> Exports are query results and the action taken when they occur. Currently
> there are two. Despite this awesome framework, there are three
> interminglings that can become issues in a production system. Feel free to
> make sub tasks for each of these three tasks:
> 1. Create PCJ independently of alerts/triggers
> At query register time (with FQF), optionally create PCJ's and optionally
> create alerts (with Alerting) preferably atomically, so if it fails in the
> middle it does not leave dangling references and garbage -- currently there
> is one method that does everything: CreatePCJ.withRyaInteraction()
> 2. Enable exporters per query -- currently all queries will be exported on
> all globally enabled exporters. When the query is registered (with FQF)
> specify the exporters that should be used.
> 3. Separate export observer queues per exporter -- Currently retrying a
> failed export observer will re-export all export types, even if some already
> succeeded, causing duplicate triggers.
> Also there is a need to refine the terms for java identifiers (for example:
> fields, classes) and documentation. Please document here a decision about
> what we name different things. The term PCJ are the index tables used by Rya
> to optimize it's queries. But sometimes it is used to describe the whole
> Fluo framework. Please define a unique term for the following. The starred
> term will be used here, but feel free to rename them:
> - Rya query optimization PCJ (ex: the Blabla exporter) PCJ*
> - Kafka trigger alert notifier (ex: the Foofoo exporter) Alerting*
> - Fluo query observer framework (ex: results from the Barbar) FQF*
> Unique identifers:
> - FQF uses QueryID
> - Alerting uses TopicID
> - PCJ uses PcjId
> Note that currently TopicID is assigned the same as QueryID, but that badly
> presupposes queryID's cannot be grouped onto one Topic.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-346) Remove Duplicate RyaExportITBase
[ https://issues.apache.org/jira/browse/RYA-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-346. --- Resolution: Fixed Fix Version/s: 3.2.11 > Remove Duplicate RyaExportITBase > > > Key: RYA-346 > URL: https://issues.apache.org/jira/browse/RYA-346 > Project: Rya > Issue Type: Bug >Affects Versions: 3.2.11 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.11 > > > The project rya.pcj.functions.geo has a duplicate version of RyaExportITBase, > which was originally created because the original RyaExportITBase was not > included in a test project. Now that a test project exists, > rya.pcj.functions.geo needs to be updated to use that dependency. This will > fix the broken tests found in GeoFunctionsIT in rya.pcj.functions.geo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-346) Remove Duplicate RyaExportITBase
[ https://issues.apache.org/jira/browse/RYA-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-346: Description: The project rya.pcj.functions.geo has a duplicate version of RyaExportITBase, which was originally created because the original RyaExportITBase was not included in a test project. Now that a test project exists, rya.pcj.functions.geo needs to be updated to use that dependency. This will fix the broken tests found in GeoFunctionsIT in rya.pcj.functions.geo. (was: The project rya.pcj.functions.geo has a duplicate version of RyaExportITBase, which was originally created by the original RyaExportITBase was not included in a test project. Not that a test project exists, rya.pcj.functions.geo needs to be updated to use that dependency. This will fix the broken tests found in GeoFunctionsIT in rya.pcj.functions.geo.) > Remove Duplicate RyaExportITBase > > > Key: RYA-346 > URL: https://issues.apache.org/jira/browse/RYA-346 > Project: Rya > Issue Type: Bug >Affects Versions: 3.2.11 >Reporter: Caleb Meier >Assignee: Caleb Meier > > The project rya.pcj.functions.geo has a duplicate version of RyaExportITBase, > which was originally created because the original RyaExportITBase was not > included in a test project. Now that a test project exists, > rya.pcj.functions.geo needs to be updated to use that dependency. This will > fix the broken tests found in GeoFunctionsIT in rya.pcj.functions.geo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-346) Remove Duplicate RyaExportITBase
Caleb Meier created RYA-346: --- Summary: Remove Duplicate RyaExportITBase Key: RYA-346 URL: https://issues.apache.org/jira/browse/RYA-346 Project: Rya Issue Type: Bug Affects Versions: 3.2.11 Reporter: Caleb Meier Assignee: Caleb Meier The project rya.pcj.functions.geo has a duplicate version of RyaExportITBase, which was originally created by the original RyaExportITBase was not included in a test project. Not that a test project exists, rya.pcj.functions.geo needs to be updated to use that dependency. This will fix the broken tests found in GeoFunctionsIT in rya.pcj.functions.geo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-295) Implement owl:allValuesFrom inference
[
https://issues.apache.org/jira/browse/RYA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-295.
---
Resolution: Fixed
Fix Version/s: 3.2.11
> Implement owl:allValuesFrom inference
> -
>
> Key: RYA-295
> URL: https://issues.apache.org/jira/browse/RYA-295
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Reporter: Jesse Hatfield
>Assignee: Jesse Hatfield
> Fix For: 3.2.11
>
>
> An *{{owl:allValuesFrom}}* restriction defines the set of resources for
> which, given a particular predicate and other type, every value of that
> predicate is a member of that type. Note that there may be no values at all.
> For example, the ontology may state that resources of type {{:Person}} have
> all values from {{:Person}} for type {{:parent}}: that is, a person's parents
> are all people as well. Therefore, a pattern of the form {{?x rdf:type
> :Person}} should be expanded to:
> {noformat}
> { ?y rdf:type :Person .
> ?y :parent ?x }
> UNION
> { ?x rdf:type :Person }
> {noformat}
> i.e. we can infer {{?x}}'s personhood from the fact that child {{?y}} is
> known to satisfy the restriction.
> Notes:
> -We can infer "x is a person, therefore all of x's parents are people". But
> we can't infer "all of x's parents are people, therefore x is a person",
> because of the open world semantics: we don't know that the parents given by
> the data are in fact all of x's parents. (If there were also a cardinality
> restriction and we could presume consistency, then we could infer this in the
> right circumstances, but this is outside the scope of basic allValuesFrom
> support.) This differs with most other property restriction rules in that we
> can't infer that an object belongs to the class defined by the restriction,
> but rather use the fact that an object is already known to belong in that
> class in order to infer something about its neighbors in the graph (the types
> of the values).
> -The example above could be applied recursively, but to implement this as a
> simple query rewrite we'll need to limit recursion depth (and interactions
> with other rules, for the same reasons).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-337) Batch Queries to MongoDB
[ https://issues.apache.org/jira/browse/RYA-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-337. --- Resolution: Fixed Fix Version/s: 3.2.11 > Batch Queries to MongoDB > > > Key: RYA-337 > URL: https://issues.apache.org/jira/browse/RYA-337 > Project: Rya > Issue Type: Improvement > Components: dao >Reporter: Aaron Mihalik >Assignee: Aaron Mihalik > Fix For: 3.2.11 > > > Currently the MongoDB DAO sends one query at a time to Mongo. Instead, the > DAO should send a batch of queries and perform a client side hash join (like > the Accumulo DAO) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-283) Incorporate Batch Operations into Fluo Workflow
[ https://issues.apache.org/jira/browse/RYA-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-283. --- Resolution: Fixed Fix Version/s: 3.2.10 > Incorporate Batch Operations into Fluo Workflow > --- > > Key: RYA-283 > URL: https://issues.apache.org/jira/browse/RYA-283 > Project: Rya > Issue Type: Bug >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > The BatchObserver framework that is currently under development needs to be > integrated with Fluo. That is, wherever results are added to Fluo from an > iterator, or whenever results are deleted within an iteration, Fluo should > instead delegate that task to the BatchObserver. This will ensure that Fluo > will not throw an OutOfMemory exception in the event that it attempts to > process an extremely large transaction. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-282) Add nested Query Support to Fluo
[
https://issues.apache.org/jira/browse/RYA-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-282.
---
Resolution: Fixed
Fix Version/s: 3.2.10
> Add nested Query Support to Fluo
>
>
> Key: RYA-282
> URL: https://issues.apache.org/jira/browse/RYA-282
> Project: Rya
> Issue Type: New Feature
>Affects Versions: 3.2.10
>Reporter: Caleb Meier
>Assignee: Caleb Meier
> Fix For: 3.2.10
>
>
> We need to add the ability to Fluo to incrementally update nested queries.
> That is, queries of the form select ?x ?y { select ?x ?y ?z { ... } }. This
> is particularly useful if we want to filter on aggregation results or use
> aggregation results in a construct query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-299) Implement rdfs:range inference
[
https://issues.apache.org/jira/browse/RYA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-299.
---
Resolution: Fixed
Fix Version/s: 3.2.10
> Implement rdfs:range inference
> --
>
> Key: RYA-299
> URL: https://issues.apache.org/jira/browse/RYA-299
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Reporter: Jesse Hatfield
>Assignee: Jesse Hatfield
> Fix For: 3.2.10
>
>
> If a predicate has an *{{rdfs:range}}* of some class, than the object of any
> triple including that predicate belongs to the class.
> If the ontology states that {{:advisor}} has the range of {{:Professor}},
> then the inference engine should rewrite queries of the form {{?x rdf:type
> :Professor}} to check for resources which are anyone's {{:advisor}} (as well
> as any specifically stated to have type {{:Professor}} ).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-298) Implement rdfs:domain inference
[
https://issues.apache.org/jira/browse/RYA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-298.
---
Resolution: Fixed
> Implement rdfs:domain inference
> ---
>
> Key: RYA-298
> URL: https://issues.apache.org/jira/browse/RYA-298
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Reporter: Jesse Hatfield
>Assignee: Jesse Hatfield
>
> If a predicate has an *{{rdfs:domain}}* of some class, than the subject of
> any triple including that predicate belongs to the class.
> If the ontology states that {{:advisor}} has the domain of {{:Person}}, then
> the inference engine should rewrite queries of the form {{?x rdf:type
> :Person}} to check for resources which have any {{:advisor}} (as well as any
> specifically stated to have type {{:Person}} ).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RYA-344) Add GetStorageType Getter to RyaDetails
[ https://issues.apache.org/jira/browse/RYA-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-344: Summary: Add GetStorageType Getter to RyaDetails (was: Add Get Storage Type Getter to RyaDetails) > Add GetStorageType Getter to RyaDetails > --- > > Key: RYA-344 > URL: https://issues.apache.org/jira/browse/RYA-344 > Project: Rya > Issue Type: Improvement > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > > Because of how Rya is currently packaged, it is difficult to configure Rya to > use the PrecomputedJoinIndexer when ingesting triples into Rya via the Rya > shell. This is in large part due to certain configuration constants not > being accessible at the API level (which is where the CLI interfaces and > other essential classes used for configuring the underlying CLI client are > located). In particular, when the configuration object created by the CLI is > modified by the RyaSailFactory (so that it is consistent with the underlying > Rya instance), it cannot set key configuration parameters to use the > PrecomputedJoinIndex (if one is enabled). The RyaDetails object currently > doesn't provide a way to determine the PrecomputedJoinStorageType (as defined > in org.apache.rya.indexing.external.PrecomputedJoinIndexerConfig) for the > underlying PCJs. A getter method that provides this storage type needs to be > added to the RyaDetails interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-344) Add Get Storage Type Getter to RyaDetails
[ https://issues.apache.org/jira/browse/RYA-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-344: Description: Because of how Rya is currently packaged, it is difficult to configure Rya to use the PrecomputedJoinIndexer when ingesting triples into Rya via the Rya shell. This is in large part due to certain configuration constants not being accessible at the API level (which is where the CLI interfaces and other essential classes used for configuring the underlying CLI client are located). In particular, when the configuration object created by the CLI is modified by the RyaSailFactory (so that it is consistent with the underlying Rya instance), it cannot set key configuration parameters to use the PrecomputedJoinIndex (if one is enabled). The RyaDetails object currently doesn't provide a way to determine the PrecomputedJoinStorageType (as defined in org.apache.rya.indexing.external.PrecomputedJoinIndexerConfig) for the underlying PCJs. A getter method that provides this storage type needs to be added to the RyaDetails interface. (was: Because of how Rya is currently packaged, it is difficult to configure Rya to use the PrecomputedJoinIndexer when ingesting triples into Rya via the Rya shell. This is large part due to certain configuration constants not being accessible at the API level (which is where the CLI interfaces and other essential classes used for configuring the underlying CLI client are located). In particular, when the configuration object created by the CLI is modified by the RyaSailFactory (so that it is consistent with the underlying Rya instance), it cannot set key configuration parameters to use the PrecomputedJoinIndex (if one is enabled). The RyaDetails object currently doesn't provide a way to determine the Storage Type for the underlying PCJs. A getter method that provides this storage type needs to be added.) > Add Get Storage Type Getter to RyaDetails > - > > Key: RYA-344 > URL: https://issues.apache.org/jira/browse/RYA-344 > Project: Rya > Issue Type: Improvement > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > > Because of how Rya is currently packaged, it is difficult to configure Rya to > use the PrecomputedJoinIndexer when ingesting triples into Rya via the Rya > shell. This is in large part due to certain configuration constants not > being accessible at the API level (which is where the CLI interfaces and > other essential classes used for configuring the underlying CLI client are > located). In particular, when the configuration object created by the CLI is > modified by the RyaSailFactory (so that it is consistent with the underlying > Rya instance), it cannot set key configuration parameters to use the > PrecomputedJoinIndex (if one is enabled). The RyaDetails object currently > doesn't provide a way to determine the PrecomputedJoinStorageType (as defined > in org.apache.rya.indexing.external.PrecomputedJoinIndexerConfig) for the > underlying PCJs. A getter method that provides this storage type needs to be > added to the RyaDetails interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-344) Add Get Storage Type Getter to RyaDetails
Caleb Meier created RYA-344: --- Summary: Add Get Storage Type Getter to RyaDetails Key: RYA-344 URL: https://issues.apache.org/jira/browse/RYA-344 Project: Rya Issue Type: Improvement Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Because of how Rya is currently packaged, it is difficult to configure Rya to use the PrecomputedJoinIndexer when ingesting triples into Rya via the Rya shell. This is large part due to certain configuration constants not being accessible at the API level (which is where the CLI interfaces and other essential classes used for configuring the underlying CLI client are located). In particular, when the configuration object created by the CLI is modified by the RyaSailFactory (so that it is consistent with the underlying Rya instance), it cannot set key configuration parameters to use the PrecomputedJoinIndex (if one is enabled). The RyaDetails object currently doesn't provide a way to determine the Storage Type for the underlying PCJs. A getter method that provides this storage type needs to be added. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-293) Implement owl:unionOf inference
[
https://issues.apache.org/jira/browse/RYA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-293.
---
Resolution: Fixed
Fix Version/s: 3.2.10
> Implement owl:unionOf inference
> ---
>
> Key: RYA-293
> URL: https://issues.apache.org/jira/browse/RYA-293
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Reporter: Jesse Hatfield
>Assignee: Jesse Hatfield
> Fix For: 3.2.10
>
>
> An *{{owl:unionOf}}* expression defines one type to be equivalent to the
> union of another set of types. If the ontology states that {{:Parent}} is the
> union of {{:Mother}} and {{:Father}}, then the inference engine should
> rewrite statement patterns of the form {{?x rdf:type :Parent}} to check for
> resources that are stated to be any of the types {{:Mother}}, {{:Father}}, or
> {{:Parent}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-306) remove generated source from git
[
https://issues.apache.org/jira/browse/RYA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier closed RYA-306.
---
Resolution: Fixed
Fix Version/s: 3.2.10
> remove generated source from git
>
>
> Key: RYA-306
> URL: https://issues.apache.org/jira/browse/RYA-306
> Project: Rya
> Issue Type: Bug
> Components: build
>Reporter: Jeff Dasch
>Assignee: Eric White
>Priority: Trivial
> Fix For: 3.2.10
>
>
> Several files in {{extras/rya.benchmark/src/main/gen}} get modified at
> compile time. They should be removed from git and configured to be created
> in {{extras/rya.benchmark/target/generated-sources}} so they can be removed
> by {{mvn clean}}.
> Files in question:
> {noformat}
> modified: extras/rya.benchmark/src/main/gen/META-INF/sun-jaxb.episode
> modified:
> extras/rya.benchmark/src/main/gen/org/apache/rya/benchmark/query/ObjectFactory.java
> modified:
> extras/rya.benchmark/src/main/gen/org/apache/rya/benchmark/query/Parameters.java
> modified:
> extras/rya.benchmark/src/main/gen/org/apache/rya/benchmark/query/QueriesBenchmarkConf.java
> modified:
> extras/rya.benchmark/src/main/gen/org/apache/rya/benchmark/query/Rya.java
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (RYA-318) Add Loading Data and Executing SPARQL Queries to the Rya Shell
[ https://issues.apache.org/jira/browse/RYA-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-318. --- Resolution: Fixed Fix Version/s: 3.2.10 > Add Loading Data and Executing SPARQL Queries to the Rya Shell > -- > > Key: RYA-318 > URL: https://issues.apache.org/jira/browse/RYA-318 > Project: Rya > Issue Type: Sub-task > Components: clients >Reporter: Jeff Dasch >Assignee: Jeff Dasch > Fix For: 3.2.10 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-317) Implement Nearby for mongo geo
[ https://issues.apache.org/jira/browse/RYA-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-317. --- Resolution: Fixed > Implement Nearby for mongo geo > -- > > Key: RYA-317 > URL: https://issues.apache.org/jira/browse/RYA-317 > Project: Rya > Issue Type: Bug >Reporter: Andrew Smith >Assignee: Andrew Smith > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-280) PeriodicQuery Support for Fluo
[ https://issues.apache.org/jira/browse/RYA-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-280: Fix Version/s: 3.2.10 > PeriodicQuery Support for Fluo > -- > > Key: RYA-280 > URL: https://issues.apache.org/jira/browse/RYA-280 > Project: Rya > Issue Type: New Feature > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add the capability to Rya-Fluo App to provide periodic updates for queries > registered with Fluo. That is, provide the application with the ability to > satisfy the standing query "tell me every 12 hours about all of the events of > a particular type that occurred within the last 24 hours". Given that Fluo > operates using a push based notification system, some external service needs > to be implemented to periodically notify Fluo to generate a result > notification (this helps handle the non-event event that occurs when nothing > happens in a given period of time). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-280) PeriodicQuery Support for Fluo
[ https://issues.apache.org/jira/browse/RYA-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-280. --- Resolution: Fixed > PeriodicQuery Support for Fluo > -- > > Key: RYA-280 > URL: https://issues.apache.org/jira/browse/RYA-280 > Project: Rya > Issue Type: New Feature > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add the capability to Rya-Fluo App to provide periodic updates for queries > registered with Fluo. That is, provide the application with the ability to > satisfy the standing query "tell me every 12 hours about all of the events of > a particular type that occurred within the last 24 hours". Given that Fluo > operates using a push based notification system, some external service needs > to be implemented to periodically notify Fluo to generate a result > notification (this helps handle the non-event event that occurs when nothing > happens in a given period of time). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-309) GeoSpatial Consistency Bug
[ https://issues.apache.org/jira/browse/RYA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-309: Fix Version/s: 3.2.10 > GeoSpatial Consistency Bug > -- > > Key: RYA-309 > URL: https://issues.apache.org/jira/browse/RYA-309 > Project: Rya > Issue Type: Bug > Components: dao >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Andrew Smith > Fix For: 3.2.10 > > > Docs are not being deleted from the geo index when the associated triple is > deleted from the triples collection. Someone needs to recreate this bug and > fix this issue so that the geo index stays consistent with the triples > collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-309) GeoSpatial Consistency Bug
[ https://issues.apache.org/jira/browse/RYA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-309. --- Resolution: Fixed > GeoSpatial Consistency Bug > -- > > Key: RYA-309 > URL: https://issues.apache.org/jira/browse/RYA-309 > Project: Rya > Issue Type: Bug > Components: dao >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Andrew Smith > Fix For: 3.2.10 > > > Docs are not being deleted from the geo index when the associated triple is > deleted from the triples collection. Someone needs to recreate this bug and > fix this issue so that the geo index stays consistent with the triples > collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (RYA-273) Construct Query Support for Rya Fluo
[ https://issues.apache.org/jira/browse/RYA-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier closed RYA-273. --- This task is complete. > Construct Query Support for Rya Fluo > > > Key: RYA-273 > URL: https://issues.apache.org/jira/browse/RYA-273 > Project: Rya > Issue Type: New Feature >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add support for Construct Queries to the Rya Fluo Application. This will > require implementing ConstructQueryMetadata for Fluo and creating the > appropriate observer to generate the statements indicated by the construct > query. See the documentation for creating a new query node for Fluo: > https://github.com/meiercaleb/incubator-rya/tree/periodic_query_service/extras/rya.pcj.fluo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-291) Implement owl:hasValue inference
[
https://issues.apache.org/jira/browse/RYA-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-291:
Affects Version/s: 3.2.10
Fix Version/s: 3.2.10
> Implement owl:hasValue inference
>
>
> Key: RYA-291
> URL: https://issues.apache.org/jira/browse/RYA-291
> Project: Rya
> Issue Type: Sub-task
> Components: sail
>Affects Versions: 3.2.10
>Reporter: Jesse Hatfield
>Assignee: Jesse Hatfield
> Fix For: 3.2.10
>
>
> *{{owl:hasValue}}* is used to define a property restriction representing the
> set of resources with a specific value for a specific predicate.
> If the ontology states that the class {{:ChildOfJohn}} represents all
> resources with {{:parent}} equal to {{:John}}, then the inference engine
> should be able to:
> 1. Rewrite a query pattern {{?X rdf:type :ChildOfJohn}} to check for
> resources whose {{:parent}} is {{:John}} (in addition to those explicitly
> stated to have type {{:ChildOfJohn}})
> 2. Rewrite a query pattern {{:Jane :parent :?Y}} to check whether :Jane has
> the type {{:ChildOfJohn}} (in addition to querying for any specifically
> stated {{:parent}} s)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (RYA-314) Update Rya Console
Caleb Meier created RYA-314: --- Summary: Update Rya Console Key: RYA-314 URL: https://issues.apache.org/jira/browse/RYA-314 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Jeff Dasch The Rya console is out of date. There are a number of features that could be added such as the ability to add an RDF file (this underlying class is implemented, it just needs to be hooked in), the ability to issue SPARQL queries through the shell. In addition, there are a large number of additions to the Rya Fluo application that need to be incorporated into the console, such as the ability to create Periodic Queries and the ability to create Construct queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (RYA-305) Wrap PeriodicNotificationApplication in Twill and Test in a Distributed Environment
[ https://issues.apache.org/jira/browse/RYA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier reassigned RYA-305: --- Assignee: Jeff Dasch (was: Caleb Meier) > Wrap PeriodicNotificationApplication in Twill and Test in a Distributed > Environment > --- > > Key: RYA-305 > URL: https://issues.apache.org/jira/browse/RYA-305 > Project: Rya > Issue Type: Sub-task > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Jeff Dasch >Priority: Critical > > In order to run the PeriodicNotificationApplication in a distributed > environment, the application needs to be wrapped in a Twill Application so > that it can be run on Yarn. After creating the Twill application, it needs > to be tested along with an updated version of the Rya-Fluo application to > verify that the service works in a timely manner. There may be some need to > adjust the Fluo config parameter "fluo.impl.ScanTask.maxSleep" which sets the > longest amount of time that Fluo sleeps for until it wakes up and processes > new results. A balance needs to be struck between the need for Fluo to be > timely and preventing a large number of unnecessary checks for "dirty cells". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-312) GeoSparl Deep Dive for Mongo
Caleb Meier created RYA-312: --- Summary: GeoSparl Deep Dive for Mongo Key: RYA-312 URL: https://issues.apache.org/jira/browse/RYA-312 Project: Rya Issue Type: Task Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Do some bench marking of geoSparql for Mongo backed Rya. Investigate how much geoSparql filters affect query performance by issuing a certain collection of geoSparql queries with and without geoSparql filters. It is important that the order of the SPARQL query be maintained throughout the benchmarking process to prevent the join evaluation from affecting the benchmark query times. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-311) Nearby GeoSparql Function
Caleb Meier created RYA-311: --- Summary: Nearby GeoSparql Function Key: RYA-311 URL: https://issues.apache.org/jira/browse/RYA-311 Project: Rya Issue Type: New Feature Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Implement a custom NearBy Filter function for finding all points that occur within a specified distance of a given point. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (RYA-307) MongoDB Bulk Load methods should use Secondary Indexer Bulk Loading
[ https://issues.apache.org/jira/browse/RYA-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier reassigned RYA-307: --- Assignee: Eric White (was: Andrew Smith) Description: The MongoDB secondary indexers *really* slow down inserts via the bulk load methods for the DAO. The DAO should use the bulk load methods on the secondary indexers. Here is where the call is made in the DAO [1] [1] https://github.com/apache/incubator-rya/blob/master/dao/mongodb.rya/src/main/java/org/apache/rya/mongodb/MongoDBRyaDAO.java#L158 Some version of a BatchWriter should be created for Mongo that is used in the DAO and any secondary indexers. was: The MongoDB secondary indexers *really* slow down inserts via the bulk load methods for the DOA. The DOA should use the bulk load methods on the secondary indexers. Here is where the call is made in the DAO [1] [1] https://github.com/apache/incubator-rya/blob/master/dao/mongodb.rya/src/main/java/org/apache/rya/mongodb/MongoDBRyaDAO.java#L158 > MongoDB Bulk Load methods should use Secondary Indexer Bulk Loading > --- > > Key: RYA-307 > URL: https://issues.apache.org/jira/browse/RYA-307 > Project: Rya > Issue Type: Improvement > Components: dao >Reporter: Aaron Mihalik >Assignee: Eric White > > The MongoDB secondary indexers *really* slow down inserts via the bulk load > methods for the DAO. The DAO should use the bulk load methods on the > secondary indexers. Here is where the call is made in the DAO [1] > [1] > https://github.com/apache/incubator-rya/blob/master/dao/mongodb.rya/src/main/java/org/apache/rya/mongodb/MongoDBRyaDAO.java#L158 > Some version of a BatchWriter should be created for Mongo that is used in the > DAO and any secondary indexers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-310) CLI Admin Tool for Mongo Rya
Caleb Meier created RYA-310: --- Summary: CLI Admin Tool for Mongo Rya Key: RYA-310 URL: https://issues.apache.org/jira/browse/RYA-310 Project: Rya Issue Type: New Feature Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier A CLI Admin tool that is similar to the CLI admin tool for Accumulo backed Rya should be created for Mongo backed Rya. Basic functionality should include getting instance details, adding and deleting users, creating and deleting PCJs, installing and uninstalling a Rya instance, loading files and issuing queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-309) GeoSpatial Consistency Bug
Caleb Meier created RYA-309: --- Summary: GeoSpatial Consistency Bug Key: RYA-309 URL: https://issues.apache.org/jira/browse/RYA-309 Project: Rya Issue Type: Bug Components: dao Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Andrew Smith Docs are not being deleted from the geo index when the associated triple is deleted from the triples collection. Someone needs to recreate this bug and fix this issue so that the geo index stays consistent with the triples collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RYA-305) Wrap PeriodicNotificationApplication in Twill and Test in a Distributed Environment
Caleb Meier created RYA-305: --- Summary: Wrap PeriodicNotificationApplication in Twill and Test in a Distributed Environment Key: RYA-305 URL: https://issues.apache.org/jira/browse/RYA-305 Project: Rya Issue Type: Sub-task Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Priority: Critical In order to run the PeriodicNotificationApplication in a distributed environment, the application needs to be wrapped in a Twill Application so that it can be run on Yarn. After creating the Twill application, it needs to be tested along with an updated version of the Rya-Fluo application to verify that the service works in a timely manner. There may be some need to adjust the Fluo config parameter "fluo.impl.ScanTask.maxSleep" which sets the longest amount of time that Fluo sleeps for until it wakes up and processes new results. A balance needs to be struck between the need for Fluo to be timely and preventing a large number of unnecessary checks for "dirty cells". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-273) Construct Query Support for Rya Fluo
[ https://issues.apache.org/jira/browse/RYA-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-273: Fix Version/s: 3.2.10 > Construct Query Support for Rya Fluo > > > Key: RYA-273 > URL: https://issues.apache.org/jira/browse/RYA-273 > Project: Rya > Issue Type: New Feature >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add support for Construct Queries to the Rya Fluo Application. This will > require implementing ConstructQueryMetadata for Fluo and creating the > appropriate observer to generate the statements indicated by the construct > query. See the documentation for creating a new query node for Fluo: > https://github.com/meiercaleb/incubator-rya/tree/periodic_query_service/extras/rya.pcj.fluo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (RYA-273) Construct Query Support for Rya Fluo
[ https://issues.apache.org/jira/browse/RYA-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-273. - Resolution: Fixed > Construct Query Support for Rya Fluo > > > Key: RYA-273 > URL: https://issues.apache.org/jira/browse/RYA-273 > Project: Rya > Issue Type: New Feature >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add support for Construct Queries to the Rya Fluo Application. This will > require implementing ConstructQueryMetadata for Fluo and creating the > appropriate observer to generate the statements indicated by the construct > query. See the documentation for creating a new query node for Fluo: > https://github.com/meiercaleb/incubator-rya/tree/periodic_query_service/extras/rya.pcj.fluo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RYA-119) Add visibility support to MongoDB
[ https://issues.apache.org/jira/browse/RYA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-119: Fix Version/s: 3.2.10 > Add visibility support to MongoDB > - > > Key: RYA-119 > URL: https://issues.apache.org/jira/browse/RYA-119 > Project: Rya > Issue Type: Improvement > Components: dao >Affects Versions: 3.2.10 >Reporter: Andrew Smith >Assignee: Eric White > Fix For: 3.2.10 > > > Currently, when querying mongo, visibility is ignored. Need to add support > for visibility when querying mongo. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RYA-273) Construct Query Support for Rya Fluo
[ https://issues.apache.org/jira/browse/RYA-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-273: Issue Type: New Feature (was: Bug) > Construct Query Support for Rya Fluo > > > Key: RYA-273 > URL: https://issues.apache.org/jira/browse/RYA-273 > Project: Rya > Issue Type: New Feature >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > > Add support for Construct Queries to the Rya Fluo Application. This will > require implementing ConstructQueryMetadata for Fluo and creating the > appropriate observer to generate the statements indicated by the construct > query. See the documentation for creating a new query node for Fluo: > https://github.com/meiercaleb/incubator-rya/tree/periodic_query_service/extras/rya.pcj.fluo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RYA-279) Some tests seem to be skipped in jenkins build
[ https://issues.apache.org/jira/browse/RYA-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-279: Fix Version/s: 3.2.10 > Some tests seem to be skipped in jenkins build > -- > > Key: RYA-279 > URL: https://issues.apache.org/jira/browse/RYA-279 > Project: Rya > Issue Type: Bug > Components: build >Reporter: Puja Valiyil >Assignee: Andrew Smith >Priority: Blocker > Fix For: 3.2.10 > > > On the dev list, there were reports of some tests being skipped by the > jenkins build. It appears that that is the case when looking at it in more > detail. Please investigate to figure out why this is an issue and if it has > something to do with naming, or something else. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-279) Some tests seem to be skipped in jenkins build
[ https://issues.apache.org/jira/browse/RYA-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-279. - Resolution: Fixed > Some tests seem to be skipped in jenkins build > -- > > Key: RYA-279 > URL: https://issues.apache.org/jira/browse/RYA-279 > Project: Rya > Issue Type: Bug > Components: build >Reporter: Puja Valiyil >Assignee: Andrew Smith >Priority: Blocker > Fix For: 3.2.10 > > > On the dev list, there were reports of some tests being skipped by the > jenkins build. It appears that that is the case when looking at it in more > detail. Please investigate to figure out why this is an issue and if it has > something to do with naming, or something else. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RYA-283) Incorporate Batch Operations into Fluo Workflow
Caleb Meier created RYA-283: --- Summary: Incorporate Batch Operations into Fluo Workflow Key: RYA-283 URL: https://issues.apache.org/jira/browse/RYA-283 Project: Rya Issue Type: Bug Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier The BatchObserver framework that is currently under development needs to be integrated with Fluo. That is, wherever results are added to Fluo from an iterator, or whenever results are deleted within an iteration, Fluo should instead delegate that task to the BatchObserver. This will ensure that Fluo will not throw an OutOfMemory exception in the event that it attempts to process an extremely large transaction. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RYA-282) Add nested Query Support to Fluo
Caleb Meier created RYA-282:
---
Summary: Add nested Query Support to Fluo
Key: RYA-282
URL: https://issues.apache.org/jira/browse/RYA-282
Project: Rya
Issue Type: New Feature
Affects Versions: 3.2.10
Reporter: Caleb Meier
Assignee: Caleb Meier
We need to add the ability to Fluo to incrementally update nested queries.
That is, queries of the form select ?x ?y { select ?x ?y ?z { ... } }. This is
particularly useful if we want to filter on aggregation results or use
aggregation results in a construct query.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (RYA-281) Decouple PCJ Creation in RYA and Fluo
Caleb Meier created RYA-281: --- Summary: Decouple PCJ Creation in RYA and Fluo Key: RYA-281 URL: https://issues.apache.org/jira/browse/RYA-281 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Currently PCJ creation in RYA and FLUO are coupled together. That is, PCJ creation within RYA is currently a prerequisite for creating a PCJ in Fluo (you need to pass in a PCJ ID when creating the Fluo metadata, and that ID is used to read information about the RYA PCJ from RyaDetails). In the past this was fine, but now we would like to be able to register a query with Fluo whose results are not necessarily being exported to a PCJ table. Another issue is that the RYA PCJ ID and the Fluo query ID don't align, which requires us to store the PCJ ID in the Fluo table so that the RYA Exporter can write results to the RYA PCJ table. These two IDs should be the same. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (RYA-246) Separate Fluo query result exporters, Rya PCJ intermingled kafka triggers
[
https://issues.apache.org/jira/browse/RYA-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier reassigned RYA-246:
---
Assignee: Caleb Meier
> Separate Fluo query result exporters, Rya PCJ intermingled kafka triggers
> -
>
> Key: RYA-246
> URL: https://issues.apache.org/jira/browse/RYA-246
> Project: Rya
> Issue Type: Improvement
> Components: dao
> Environment: Fluo, Kafka, PCJ, Accumulo
>Reporter: David W. Lotts
>Assignee: Caleb Meier
>
> Currently the Fluo query observer framework (FQF) has a great plugin-in-ish
> way of doing exports. (See field: {{exporters}} in class:
> {{org.apache.rya.indexing.pcj.fluo.app.observers.QueryResultObserver}} )
> Exports are query results and the action taken when they occur. Currently
> there are two. Despite this awesome framework, there are three
> interminglings that can become issues in a production system. Feel free to
> make sub tasks for each of these three tasks:
> 1. Create PCJ independently of alerts/triggers
> At query register time (with FQF), optionally create PCJ's and optionally
> create alerts (with Alerting) preferably atomically, so if it fails in the
> middle it does not leave dangling references and garbage -- currently there
> is one method that does everything: CreatePCJ.withRyaInteraction()
> 2. Enable exporters per query -- currently all queries will be exported on
> all globally enabled exporters. When the query is registered (with FQF)
> specify the exporters that should be used.
> 3. Separate export observer queues per exporter -- Currently retrying a
> failed export observer will re-export all export types, even if some already
> succeeded, causing duplicate triggers.
> Also there is a need to refine the terms for java identifiers (for example:
> fields, classes) and documentation. Please document here a decision about
> what we name different things. The term PCJ are the index tables used by Rya
> to optimize it's queries. But sometimes it is used to describe the whole
> Fluo framework. Please define a unique term for the following. The starred
> term will be used here, but feel free to rename them:
> - Rya query optimization PCJ (ex: the Blabla exporter) PCJ*
> - Kafka trigger alert notifier (ex: the Foofoo exporter) Alerting*
> - Fluo query observer framework (ex: results from the Barbar) FQF*
> Unique identifers:
> - FQF uses QueryID
> - Alerting uses TopicID
> - PCJ uses PcjId
> Note that currently TopicID is assigned the same as QueryID, but that badly
> presupposes queryID's cannot be grouped onto one Topic.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (RYA-280) PeriodicQuery Support for Fluo
Caleb Meier created RYA-280: --- Summary: PeriodicQuery Support for Fluo Key: RYA-280 URL: https://issues.apache.org/jira/browse/RYA-280 Project: Rya Issue Type: New Feature Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Add the capability to Rya-Fluo App to provide periodic updates for queries registered with Fluo. That is, provide the application with the ability to satisfy the standing query "tell me every 12 hours about all of the events of a particular type that occurred within the last 24 hours". Given that Fluo operates using a push based notification system, some external service needs to be implemented to periodically notify Fluo to generate a result notification (this helps handle the non-event event that occurs when nothing happens in a given period of time). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (RYA-276) MergeJoin returns incorrect results if first iterator must advance
[ https://issues.apache.org/jira/browse/RYA-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15996732#comment-15996732 ] Caleb Meier edited comment on RYA-276 at 5/4/17 1:38 PM: - MergeJoin is not used anywhere in the evaluation process (or any where else in the code base for that matter). As a matter of fact, I'm pretty sure that the entire package org.apache.rya.api.persist.query.join is not used. We should delete this to avoid any further confusion. was (Author: meierca...@gmail.com): MergeJoin is not used anywhere in the evaluation process. As a matter of fact, I'm pretty sure that the entire package org.apache.rya.api.persist.query.join is not used. We should delete this to avoid any further confusion. > MergeJoin returns incorrect results if first iterator must advance > -- > > Key: RYA-276 > URL: https://issues.apache.org/jira/browse/RYA-276 > Project: Rya > Issue Type: Bug > Components: dao >Affects Versions: 3.2.10, 3.2.9 >Reporter: Jonathan Wonders >Priority: Minor > Attachments: 0001-Adding-tests-to-illustrate-merge-join-bug.patch > > > The algorithm used for intersecting iterations over statements produces > incorrect output for some types of input sequences. > If the first iterator must advance due to the initial value of the first > iterator preceding the initial value of a secondary iterator, the returned > object will still be taken from the initial statement of the first iterator > rather than the last statement it advanced to. This is easy to fix by > updating the current statement alongside the current object. > There is another more complicated issue when the input data requires > advancing a secondary iterator followed by advancing the first iterator (and > optionally continuing to advance both back and forth). The first iterator > will never be advanced after an object greater than the current value of the > first iterator is found. This scenario occurs frequently in the wild when > two iterators seek past each others latest value prior to finding one that > appears in both. The current implementation will include spurious results. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RYA-276) MergeJoin returns incorrect results if first iterator must advance
[ https://issues.apache.org/jira/browse/RYA-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15996732#comment-15996732 ] Caleb Meier commented on RYA-276: - MergeJoin is not used anywhere in the evaluation process. As a matter of fact, I'm pretty sure that the entire package org.apache.rya.api.persist.query.join is not used. We should delete this to avoid any further confusion. > MergeJoin returns incorrect results if first iterator must advance > -- > > Key: RYA-276 > URL: https://issues.apache.org/jira/browse/RYA-276 > Project: Rya > Issue Type: Bug > Components: dao >Affects Versions: 3.2.10, 3.2.9 >Reporter: Jonathan Wonders >Priority: Minor > Attachments: 0001-Adding-tests-to-illustrate-merge-join-bug.patch > > > The algorithm used for intersecting iterations over statements produces > incorrect output for some types of input sequences. > If the first iterator must advance due to the initial value of the first > iterator preceding the initial value of a secondary iterator, the returned > object will still be taken from the initial statement of the first iterator > rather than the last statement it advanced to. This is easy to fix by > updating the current statement alongside the current object. > There is another more complicated issue when the input data requires > advancing a secondary iterator followed by advancing the first iterator (and > optionally continuing to advance both back and forth). The first iterator > will never be advanced after an object greater than the current value of the > first iterator is found. This scenario occurs frequently in the wild when > two iterators seek past each others latest value prior to finding one that > appears in both. The current implementation will include spurious results. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-260) Add Aggregation support for Fluo/PCJ app
[
https://issues.apache.org/jira/browse/RYA-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier resolved RYA-260.
-
Resolution: Fixed
> Add Aggregation support for Fluo/PCJ app
>
>
> Key: RYA-260
> URL: https://issues.apache.org/jira/browse/RYA-260
> Project: Rya
> Issue Type: New Feature
>Reporter: Andrew Smith
>Assignee: Kevin Chilton
> Fix For: 3.2.10
>
>
> A user must be able to submit a PCJ query that contains the following
> aggregation functions from SPARQL:
> * Sum
> * Count
> * Average
> * Min
> * Max
> This task does not include any aggregations that appear within a GroupBy
> clause. We only need to support queries that have the aggregation within the
> SELECT section.
> For example, the following query should be processed:
> {code}
> SELECT (avg(?price) as ?averagePrice)
> {
> urn:BookA urn:price ?price.
> }
> {code}
> And the following query should not be processed because it requires a group
> by:
> {code}
> SELECT ?title (avg(?price) as ?averagePrice)
> {
> ?title urn:price ?price.
> }
> GROUP BY ?title
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (RYA-260) Add Aggregation support for Fluo/PCJ app
[
https://issues.apache.org/jira/browse/RYA-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-260:
Fix Version/s: 3.2.10
> Add Aggregation support for Fluo/PCJ app
>
>
> Key: RYA-260
> URL: https://issues.apache.org/jira/browse/RYA-260
> Project: Rya
> Issue Type: New Feature
>Reporter: Andrew Smith
>Assignee: Kevin Chilton
> Fix For: 3.2.10
>
>
> A user must be able to submit a PCJ query that contains the following
> aggregation functions from SPARQL:
> * Sum
> * Count
> * Average
> * Min
> * Max
> This task does not include any aggregations that appear within a GroupBy
> clause. We only need to support queries that have the aggregation within the
> SELECT section.
> For example, the following query should be processed:
> {code}
> SELECT (avg(?price) as ?averagePrice)
> {
> urn:BookA urn:price ?price.
> }
> {code}
> And the following query should not be processed because it requires a group
> by:
> {code}
> SELECT ?title (avg(?price) as ?averagePrice)
> {
> ?title urn:price ?price.
> }
> GROUP BY ?title
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (RYA-273) Construct Query Support for Rya Fluo
Caleb Meier created RYA-273: --- Summary: Construct Query Support for Rya Fluo Key: RYA-273 URL: https://issues.apache.org/jira/browse/RYA-273 Project: Rya Issue Type: Bug Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Add support for Construct Queries to the Rya Fluo Application. This will require implementing ConstructQueryMetadata for Fluo and creating the appropriate observer to generate the statements indicated by the construct query. See the documentation for creating a new query node for Fluo: https://github.com/meiercaleb/incubator-rya/tree/periodic_query_service/extras/rya.pcj.fluo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-261) Context Validation for StatementPattern Evaluation
[
https://issues.apache.org/jira/browse/RYA-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier resolved RYA-261.
-
Resolution: Fixed
> Context Validation for StatementPattern Evaluation
> --
>
> Key: RYA-261
> URL: https://issues.apache.org/jira/browse/RYA-261
> Project: Rya
> Issue Type: Bug
> Components: clients, dao
>Affects Versions: 3.2.10
>Reporter: Caleb Meier
>Assignee: Caleb Meier
> Fix For: 3.2.10
>
>
> When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
> take into account the possibility that context can be specified by the
> BindingSet parameter passed into its evaluate method. The evaluate method
> scans Rya by building an Accumulo Range using all values relevant to the
> Accumulo Row that are included in the StatementPattern and BindingSet.
> However, it does not utilize context when building it Range object because
> context is stored in the Accumulo Column Family. The results of this scan
> are effectively (Statement, BindingSet) pairs that are joined to form a
> result BindingSet. This join process does not take into account the fact
> that the BindingSet could contain a value for the context that is not the
> same as the context value in the Statement. As an example of this incorrect
> behavior, consider the following named graph query:
> select ?c ?x where{ graph ?c { ?x ;
> }}
> If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
> uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya, the above
> query will incorrectly return [?x = uri:Joe, ?c = context1] when it should
> return no results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (RYA-253) Refactor rya.prospector to use Java instead of Groovy
[ https://issues.apache.org/jira/browse/RYA-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-253. - Resolution: Fixed > Refactor rya.prospector to use Java instead of Groovy > - > > Key: RYA-253 > URL: https://issues.apache.org/jira/browse/RYA-253 > Project: Rya > Issue Type: Bug >Reporter: Kevin Chilton >Assignee: Kevin Chilton > Fix For: 3.2.10 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RYA-253) Refactor rya.prospector to use Java instead of Groovy
[ https://issues.apache.org/jira/browse/RYA-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-253: Fix Version/s: 3.2.10 > Refactor rya.prospector to use Java instead of Groovy > - > > Key: RYA-253 > URL: https://issues.apache.org/jira/browse/RYA-253 > Project: Rya > Issue Type: Bug >Reporter: Kevin Chilton >Assignee: Kevin Chilton > Fix For: 3.2.10 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RYA-272) Create Geo examples in Geo Project
Caleb Meier created RYA-272: --- Summary: Create Geo examples in Geo Project Key: RYA-272 URL: https://issues.apache.org/jira/browse/RYA-272 Project: Rya Issue Type: Task Components: examples Affects Versions: 3.2.10 Reporter: Caleb Meier There are a number of old geo examples in the examples in the Indexing Example project that are commented out. These need to be removed and used to form an example class for the geo project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-270) Can not resolve the GeoWave dependencies.
[
https://issues.apache.org/jira/browse/RYA-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier resolved RYA-270.
-
Resolution: Fixed
> Can not resolve the GeoWave dependencies.
> -
>
> Key: RYA-270
> URL: https://issues.apache.org/jira/browse/RYA-270
> Project: Rya
> Issue Type: Bug
>Reporter: Kevin Chilton
>Assignee: Aaron Mihalik
>Priority: Blocker
> Fix For: 3.2.10
>
>
> When building a fresh checkout of Rya, the following build failure occurs.
> {code}
> [ERROR] Failed to execute goal on project rya.geoindexing: Could not resolve
> dependencies for project
> org.apache.rya:rya.geoindexing:jar:3.2.11-incubating-SNAPSHOT: The following
> artifacts could not be resolved:
> mil.nga.giat:geowave-datastore-accumulo:jar:0.9.3,
> mil.nga.giat:geowave-adapter-vector:jar:0.9.3: Failure to find
> mil.nga.giat:geowave-datastore-accumulo:jar:0.9.3 in
> http://download.osgeo.org/webdav/geotools/ was cached in the local
> repository, resolution will not be reattempted until the update interval of
> osgeo has elapsed or updates are forced -> [Help 1]
> {code}
> It looks like the repository that hosts these jars is no longer available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (RYA-270) Can not resolve the GeoWave dependencies.
[
https://issues.apache.org/jira/browse/RYA-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-270:
Fix Version/s: 3.2.10
> Can not resolve the GeoWave dependencies.
> -
>
> Key: RYA-270
> URL: https://issues.apache.org/jira/browse/RYA-270
> Project: Rya
> Issue Type: Bug
>Reporter: Kevin Chilton
>Assignee: Aaron Mihalik
>Priority: Blocker
> Fix For: 3.2.10
>
>
> When building a fresh checkout of Rya, the following build failure occurs.
> {code}
> [ERROR] Failed to execute goal on project rya.geoindexing: Could not resolve
> dependencies for project
> org.apache.rya:rya.geoindexing:jar:3.2.11-incubating-SNAPSHOT: The following
> artifacts could not be resolved:
> mil.nga.giat:geowave-datastore-accumulo:jar:0.9.3,
> mil.nga.giat:geowave-adapter-vector:jar:0.9.3: Failure to find
> mil.nga.giat:geowave-datastore-accumulo:jar:0.9.3 in
> http://download.osgeo.org/webdav/geotools/ was cached in the local
> repository, resolution will not be reattempted until the update interval of
> osgeo has elapsed or updates are forced -> [Help 1]
> {code}
> It looks like the repository that hosts these jars is no longer available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (RYA-261) Context Validation for StatementPattern Evaluation
[
https://issues.apache.org/jira/browse/RYA-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-261:
Description:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. As an example of this incorrect behavior, consider the
following named graph query:
select ?c ?x where{ graph ?c { ?x ;
}}
If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya, the above query
will incorrectly return [?x = uri:Joe, ?c = context1] when it should return no
results.
was:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x where{ graph ?c { ?x ;
}}
If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya the above query
will incorrectly return [?x = uri:Joe, ?c = context2] when it should return no
results.
> Context Validation for StatementPattern Evaluation
> --
>
> Key: RYA-261
> URL: https://issues.apache.org/jira/browse/RYA-261
> Project: Rya
> Issue Type: Bug
> Components: clients, dao
>Affects Versions: 3.2.10
>Reporter: Caleb Meier
>Assignee: Caleb Meier
> Fix For: 3.2.10
>
>
> When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
> take into account the possibility that context can be specified by the
> BindingSet parameter passed into its evaluate method. The evaluate method
> scans Rya by building an Accumulo Range using all values relevant to the
> Accumulo Row that are included in the StatementPattern and BindingSet.
> However, it does not utilize context when building it Range object because
> context is stored in the Accumulo Column Family. The results of this scan
> are effectively (Statement, BindingSet) pairs that are joined to form a
> result BindingSet. This join process does not take into account the fact
> that the BindingSet could contain a value for the context that is not the
> same as the context value in the Statement. As an example of this incorrect
> behavior, consider the following named graph query:
> select ?c ?x where{ graph ?c { ?x ;
> }}
> If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
> uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya, the above
> query will incorrectly return [?x = uri:Joe, ?c = context1] when it should
> return no results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (RYA-261) Context Validation for StatementPattern Evaluation
[
https://issues.apache.org/jira/browse/RYA-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-261:
Description:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x where{ graph ?c { ?x ;
}}
If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya the above query
will incorrectly return [?x = uri:Joe, ?c = context2] when it should return no
results.
was:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x from graph ?c {where { ?x ;
}}
If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya the above query
will incorrectly return [?x = uri:Joe, ?c = context2] when it should return no
results.
> Context Validation for StatementPattern Evaluation
> --
>
> Key: RYA-261
> URL: https://issues.apache.org/jira/browse/RYA-261
> Project: Rya
> Issue Type: Bug
> Components: clients, dao
>Affects Versions: 3.2.10
>Reporter: Caleb Meier
>Assignee: Caleb Meier
> Fix For: 3.2.10
>
>
> When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
> take into account the possibility that context can be specified by the
> BindingSet parameter passed into its evaluate method. The evaluate method
> scans Rya by building an Accumulo Range using all values relevant to the
> Accumulo Row that are included in the StatementPattern and BindingSet.
> However, it does not utilize context when building it Range object because
> context is stored in the Accumulo Column Family. The results of this scan
> are effectively (Statement, BindingSet) pairs that are joined to form a
> result BindingSet. This join process does not take into account the fact
> that the BindingSet could contain a value for the context that is not the
> same as the context value in the Statement. The context for the Statement is
> extracted and written to the BindingSet, possibly overwriting any value of
> context that was there. Such behavior occurs when one queries for the named
> graph of Rya statements
> select ?c ?x where{ graph ?c { ?x ;
> }}
> If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
> uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya the above query
> will incorrectly return [?x = uri:Joe, ?c = context2] when it should return
> no results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (RYA-261) Context Validation for StatementPattern Evaluation
[
https://issues.apache.org/jira/browse/RYA-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-261:
Description:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x from graph ?c {where { ?x ;
}}
If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya the above query
will incorrectly return [?x = uri:Joe, ?c = context2] when it should return no
results.
was:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x from graph ?c {where { ?x ;
}}
with the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) in Rya. Because of the bug
described above, the above query will incorrectly return [?x = uri:Joe, ?c =
context2] when it should return no results.
> Context Validation for StatementPattern Evaluation
> --
>
> Key: RYA-261
> URL: https://issues.apache.org/jira/browse/RYA-261
> Project: Rya
> Issue Type: Bug
> Components: clients, dao
>Affects Versions: 3.2.10
>Reporter: Caleb Meier
>Assignee: Caleb Meier
> Fix For: 3.2.10
>
>
> When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
> take into account the possibility that context can be specified by the
> BindingSet parameter passed into its evaluate method. The evaluate method
> scans Rya by building an Accumulo Range using all values relevant to the
> Accumulo Row that are included in the StatementPattern and BindingSet.
> However, it does not utilize context when building it Range object because
> context is stored in the Accumulo Column Family. The results of this scan
> are effectively (Statement, BindingSet) pairs that are joined to form a
> result BindingSet. This join process does not take into account the fact
> that the BindingSet could contain a value for the context that is not the
> same as the context value in the Statement. The context for the Statement is
> extracted and written to the BindingSet, possibly overwriting any value of
> context that was there. Such behavior occurs when one queries for the named
> graph of Rya statements
> select ?c ?x from graph ?c {where { ?x ;
> }}
> If the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
> uri:worksAt, uri:GroceryStore, uri:context2) is stored in Rya the above query
> will incorrectly return [?x = uri:Joe, ?c = context2] when it should return
> no results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (RYA-261) Context Validation for StatementPattern Evaluation
[
https://issues.apache.org/jira/browse/RYA-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Meier updated RYA-261:
Description:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context when building it Range object because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x from graph ?c {where { ?x ;
}}
with the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) in Rya. Because of the bug
described above, the above query will incorrectly return [?x = uri:Joe, ?c =
context2] when it should return no results.
was:
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Row Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context during the evaluation process because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x from graph ?c {where { ?x ;
}}
with the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) in Rya. Because of the bug
described above, the above query will incorrectly return [?x = uri:Joe, ?c =
context2] when it should return no results.
> Context Validation for StatementPattern Evaluation
> --
>
> Key: RYA-261
> URL: https://issues.apache.org/jira/browse/RYA-261
> Project: Rya
> Issue Type: Bug
> Components: clients, dao
>Affects Versions: 3.2.10
>Reporter: Caleb Meier
>Assignee: Caleb Meier
> Fix For: 3.2.10
>
>
> When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
> take into account the possibility that context can be specified by the
> BindingSet parameter passed into its evaluate method. The evaluate method
> scans Rya by building an Accumulo Range using all values relevant to the
> Accumulo Row that are included in the StatementPattern and BindingSet.
> However, it does not utilize context when building it Range object because
> context is stored in the Accumulo Column Family. The results of this scan
> are effectively (Statement, BindingSet) pairs that are joined to form a
> result BindingSet. This join process does not take into account the fact
> that the BindingSet could contain a value for the context that is not the
> same as the context value in the Statement. The context for the Statement is
> extracted and written to the BindingSet, possibly overwriting any value of
> context that was there. Such behavior occurs when one queries for the named
> graph of Rya statements
> select ?c ?x from graph ?c {where { ?x ;
> }}
> with the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
> uri:worksAt, uri:GroceryStore, uri:context2) in Rya. Because of the bug
> described above, the above query will incorrectly return [?x = uri:Joe, ?c =
> context2] when it should return no results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (RYA-261) Context Validation for StatementPattern Evaluation
Caleb Meier created RYA-261:
---
Summary: Context Validation for StatementPattern Evaluation
Key: RYA-261
URL: https://issues.apache.org/jira/browse/RYA-261
Project: Rya
Issue Type: Bug
Components: clients, dao
Affects Versions: 3.2.10
Reporter: Caleb Meier
Assignee: Caleb Meier
Fix For: 3.2.10
When ParallelEvaluationStrategyImpl evaluates StatementPatterns, it doesn't
take into account the possibility that context can be specified by the
BindingSet parameter passed into its evaluate method. The evaluate method
scans Rya by building an Accumulo Row Range using all values relevant to the
Accumulo Row that are included in the StatementPattern and BindingSet. However,
it does not utilize context during the evaluation process because context is
stored in the Accumulo Column Family. The results of this scan are effectively
(Statement, BindingSet) pairs that are joined to form a result BindingSet.
This join process does not take into account the fact that the BindingSet could
contain a value for the context that is not the same as the context value in
the Statement. The context for the Statement is extracted and written to the
BindingSet, possibly overwriting any value of context that was there. Such
behavior occurs when one queries for the named graph of Rya statements
select ?c ?x from graph ?c {where { ?x ;
}}
with the data (uri:Joe, uri:talksTo, uri:Bob, uri:context1), (uri:Joe,
uri:worksAt, uri:GroceryStore, uri:context2) in Rya. Because of the bug
described above, the above query will incorrectly return [?x = uri:Joe, ?c =
context2] when it should return no results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (RYA-252) Spark Query Engine
Caleb Meier created RYA-252: --- Summary: Spark Query Engine Key: RYA-252 URL: https://issues.apache.org/jira/browse/RYA-252 Project: Rya Issue Type: New Feature Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Create a SparkQueryEngine that uses AccumuloInputFormat to load StatementPattern scans into Dataframes and then performs the SQL equivalent of the SPARQL query on the Dataframes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-227) Extend RyaDetailToConfiguration to handle invalid Fluo App Name and No Statistics Tables
[ https://issues.apache.org/jira/browse/RYA-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-227. - Resolution: Fixed This has been resolved. > Extend RyaDetailToConfiguration to handle invalid Fluo App Name and No > Statistics Tables > > > Key: RYA-227 > URL: https://issues.apache.org/jira/browse/RYA-227 > Project: Rya > Issue Type: Bug > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Currently the class RyaDetailsToConfiguration compares RyaDetails information > with user specified configuration and adjusts the user's configuration so > that it is consistent with the instance. Right now, only user indexer > configuration flags are checked to see if they are consistent with the Rya > Instance. There is currently no check to verify whether or not a user > specified Fluo Updater Application is consistent with a Rya Instance and > there is no check to make sure the cardinality and join selectivity tables > exist if a user indicates that they want to use statistics. These checks > need to put in place. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-226) Create Config Builders and Eliminate Duplicate Configuration Keys
[ https://issues.apache.org/jira/browse/RYA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-226. - Resolution: Fixed Fix Version/s: 3.2.10 Builders have been implemented. There is an outstanding pull request for this ticket. > Create Config Builders and Eliminate Duplicate Configuration Keys > - > > Key: RYA-226 > URL: https://issues.apache.org/jira/browse/RYA-226 > Project: Rya > Issue Type: New Feature > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Create a nested hierarchy of configuration builders to make the construction > of configuration objects easier. Also, eliminate duplicate and unused > configuration keys. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RYA-234) StatementMetaData Optimizer
[ https://issues.apache.org/jira/browse/RYA-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-234. - Resolution: Fixed Fix Version/s: 3.2.10 StatementMetadata Optimizer has been implemented with tests and an example in RyaDirectExamples. > StatementMetaData Optimizer > --- > > Key: RYA-234 > URL: https://issues.apache.org/jira/browse/RYA-234 > Project: Rya > Issue Type: New Feature > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Create a Statement Meta data query node and an optimizer to match such nodes. > The purpose of the node is to match reified queries for statement metadata > and during evaluation, issue the appropriate scan to Rya to extract the > metadata. The objective here is to reduce the number of joins required to > query metadata for a given statement. The reified metadata query will be > reduced to a single scan where metadata properties are extracted from the > value field of each serialized Rya statement. The user will have the option > of specifying which metadata properties to query over in the event that some > of the triples have been reified and others have not. If no statement > metadata properties are specified, all properties associated with the reified > blank node will be packaged into the StatementMetadataNode and only triples > satisfying all of those properties will be returned (along with the values of > the specified properties). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RYA-234) StatementMetaData Optimizer
Caleb Meier created RYA-234: --- Summary: StatementMetaData Optimizer Key: RYA-234 URL: https://issues.apache.org/jira/browse/RYA-234 Project: Rya Issue Type: New Feature Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Create a Statement Meta data query node and an optimizer to match such nodes. The purpose of the node is to match reified queries for statement metadata and during evaluation, issue the appropriate scan to Rya to extract the metadata. The objective here is to reduce the number of joins required to query metadata for a given statement. The reified metadata query will be reduced to a single scan where metadata properties are extracted from the value field of each serialized Rya statement. The user will have the option of specifying which metadata properties to query over in the event that some of the triples have been reified and others have not. If no statement metadata properties are specified, all properties associated with the reified blank node will be packaged into the StatementMetadataNode and only triples satisfying all of those properties will be returned (along with the values of the specified properties). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-222) Include Column Visibilities when Importing Historical Results into Fluo
[ https://issues.apache.org/jira/browse/RYA-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-222. - Resolution: Fixed > Include Column Visibilities when Importing Historical Results into Fluo > --- > > Key: RYA-222 > URL: https://issues.apache.org/jira/browse/RYA-222 > Project: Rya > Issue Type: Bug >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > When a new PCJ is registered in with Fluo, the Rya Fluo App needs to import > historical results from the core Rya tables into Fluo. This is done by > calling CreatePcj#withRyaIntegration. When historical triples are added, > their column visibilities are not also being included. This allows users to > potentially access triples that they are not authorized to access when using > PCJs to evalauate queries. To prevent this, the CreatePcj#withRyaIntegration > method needs to be updated so that visibilities are included when historical > triples are ingested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-224) Rya Fluo Application Visibility Join Bug
[ https://issues.apache.org/jira/browse/RYA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-224. - Resolution: Fixed > Rya Fluo Application Visibility Join Bug > > > Key: RYA-224 > URL: https://issues.apache.org/jira/browse/RYA-224 > Project: Rya > Issue Type: Bug >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > There is a bug in how the Rya Fluo application processes joins for BindingSet > results with visibilities. When a new BindingSet join result is processed by > the JoinObserver for a given node, it scans for results associated with the > sibling node. When the triggering BindingSet has a visibility, there is > currently a bug with how the scan prefix is formed to scan the sibling > results. The visibility is incorrectly added to the String to form the > prefix, leading to missed results in certain situations. Line 153 in > JoinResultUpdater needs to be changed to remedy this problem. In particular, > the "childBindingSetString" formed on that line needs to be split on the > delimiter "\u0001" to remove the visibility appended to that String by the > VisibilityBindingSetStringConverter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-227) Extend RyaDetailToConfiguration to handle invalid Fluo App Name and No Statistics Tables
Caleb Meier created RYA-227: --- Summary: Extend RyaDetailToConfiguration to handle invalid Fluo App Name and No Statistics Tables Key: RYA-227 URL: https://issues.apache.org/jira/browse/RYA-227 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Fix For: 3.2.10 Currently the class RyaDetailsToConfiguration compares RyaDetails information with user specified configuration and adjusts the user's configuration so that it is consistent with the instance. Right now, only user indexer configuration flags are checked to see if they are consistent with the Rya Instance. There is currently no check to verify whether or not a user specified Fluo Updater Application is consistent with a Rya Instance and there is no check to make sure the cardinality and join selectivity tables exist if a user indicates that they want to use statistics. These checks need to put in place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-226) Create Config Builders and Eliminate Duplicate Configuration Keys
Caleb Meier created RYA-226: --- Summary: Create Config Builders and Eliminate Duplicate Configuration Keys Key: RYA-226 URL: https://issues.apache.org/jira/browse/RYA-226 Project: Rya Issue Type: New Feature Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Create a nested hierarchy of configuration builders to make the construction of configuration objects easier. Also, eliminate duplicate and unused configuration keys. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-224) Rya Fluo Application Visibility Join Bug
Caleb Meier created RYA-224: --- Summary: Rya Fluo Application Visibility Join Bug Key: RYA-224 URL: https://issues.apache.org/jira/browse/RYA-224 Project: Rya Issue Type: Bug Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Fix For: 3.2.10 There is a bug in how the Rya Fluo application processes joins for BindingSet results with visibilities. When a new BindingSet join result is processed by the JoinObserver for a given node, it scans for results associated with the sibling node. When the triggering BindingSet has a visibility, there is currently a bug with how the scan prefix is formed to scan the sibling results. The visibility is incorrectly added to the String to form the prefix, leading to missed results in certain situations. Line 153 in JoinResultUpdater needs to be changed to remedy this problem. In particular, the "childBindingSetString" formed on that line needs to be split on the delimiter "\u0001" to remove the visibility appended to that String by the VisibilityBindingSetStringConverter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-153) PCJ Matching Bug
[ https://issues.apache.org/jira/browse/RYA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-153. - Resolution: Fixed Fix Version/s: 3.2.10 > PCJ Matching Bug > > > Key: RYA-153 > URL: https://issues.apache.org/jira/browse/RYA-153 > Project: Rya > Issue Type: Bug > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > There is a bug in how the PCJOptimizer matches PCJs to sub-queries. As it's > currently implemented, the PCJOptimizer decomposes queries into JoinSegments > (portions of the query which contain only Joins) and LeftJoinSegments > (portions of the query which contain Joins and LeftJoins). Each of these > segment types has an associated matcher (JoinSegmentMatcher and > LeftJoinSegmentMatcher) which performs the task of matching the PCJ queries > to sub-queries of the respective segment. The JoinSegmentMatcher currently > attempts to match the PCJs with LeftJoins to some sub-query of that segment. > From an optimization point of view, it shouldn't attempt this match given > that the PCJ contains LeftJoins and the JoinSegment doesn't (a match will > never occur). But because the JoinSegmentMatcher isn't designed to handle > LeftJoins, there is also buggy matching behavior occurring. So there needs > to be some sort of input validation for the JoinSegmentMatcher to prevent the > attempted match of a PCJ with LeftJoins to a JoinQuerySegment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-154) Decouple Configuration for Using PCJs and Using PCJ updater
[ https://issues.apache.org/jira/browse/RYA-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-154. - Resolution: Fixed > Decouple Configuration for Using PCJs and Using PCJ updater > --- > > Key: RYA-154 > URL: https://issues.apache.org/jira/browse/RYA-154 > Project: Rya > Issue Type: Bug > Components: clients, dao >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > > When a user configures a Rya Client to use Precomputed Joins for querying, it > also adds the PrecomputedJoinIndexer to the list of additional indices. This > should not be the case as the PrecomputedJoinIndexer is used to incrementally > update PCJs as data is ingested, while enabling PCJs is a query client > feature that can be used to boost query performance. Given the different > roles of these two features, their configuration should be decoupled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-223) LeftJoin Column Visibility Bug in Rya Fluo App
Caleb Meier created RYA-223: --- Summary: LeftJoin Column Visibility Bug in Rya Fluo App Key: RYA-223 URL: https://issues.apache.org/jira/browse/RYA-223 Project: Rya Issue Type: Bug Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Fix For: 3.2.10 The column visibilities for LeftJoin results in the Rya Fluo App are not being handled correctly. For a given query Q1, if the BindingSet [x = Bob, y = Dog] has visibility v_1 is LeftJoined with the BindingSet [x=Bob, z = Cat] with visibility v_2, the resulting BindingSet [x = Bob, y = Dog, z = Cat] with visibility v_1&v_2 is written to Fluo. In the event that a user with authorization v_1 issues the query Q1 and uses PCJs, he will not see the result [x = Bob, y = Dog, z = Cat] given that it has visibilities v_1&v_2. Given that the query is is a LeftJoin, the user should see the result [x = Bob, y = Dog] (which has visibility v_1), but he doesn't because this BindingSet is not being written. So when the LeftJoin for Q1 is evaluated using BindingSets with different visibilities, the joined result (with concatenated visibilities) and the left BindingSet should be written to Fluo. So in the above example, the results [x = Bob, y = Dog, z = Cat] with visibility v_1&v_2 and [x = Bob, y = Dog] with visibility v_1 should be written to the Fluo table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-222) Include Column Visibilities when Importing Historical Results into Fluo
Caleb Meier created RYA-222: --- Summary: Include Column Visibilities when Importing Historical Results into Fluo Key: RYA-222 URL: https://issues.apache.org/jira/browse/RYA-222 Project: Rya Issue Type: Bug Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Fix For: 3.2.10 When a new PCJ is registered in with Fluo, the Rya Fluo App needs to import historical results from the core Rya tables into Fluo. This is done by calling CreatePcj#withRyaIntegration. When historical triples are added, their column visibilities are not also being included. This allows users to potentially access triples that they are not authorized to access when using PCJs to evalauate queries. To prevent this, the CreatePcj#withRyaIntegration method needs to be updated so that visibilities are included when historical triples are ingested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (RYA-214) Query Metadata Input Validation for CreatePcj
[ https://issues.apache.org/jira/browse/RYA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier reassigned RYA-214: --- Assignee: Caleb Meier > Query Metadata Input Validation for CreatePcj > - > > Key: RYA-214 > URL: https://issues.apache.org/jira/browse/RYA-214 > Project: Rya > Issue Type: Bug > Components: clients >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > When the method CreatePcj#withRyaIntegration is called, it creates the query > metadata for Fluo and then populates Fluo with historical results form Rya. > Before the metadata gets inserted, it's necessary to verify that the parsed > query only consists of StatementPatterns, Joins, Leftjoins, Filters, and a > Projection -- these are the only nodes that currently have observers > implemented. Right now there is a visitor which attempts to verify this -- > it has a meet method for each of the allowed node types -- but it has no meet > method for other node types that are not allowed so it just skips these > nodes. So in effect, for a given query, this visitor goes through and > creates metadata only for nodes that are allowed in Fluo, and ignores invalid > nodes. The bug here is that if the user attempts to insert a query with an > invalid query node into Fluo, this method will insert a different query into > Fluo (the query obtained from the original by removing the invalid nodes). > The input validation visitor should traverse the query, creating metadata, > and either insert all of the metadata if the visitor traverses the entire > query without encountering an invalid node, or throw an exception if an > invalid node is an encountered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-214) Query Metadata Input Validation for CreatePcj
Caleb Meier created RYA-214: --- Summary: Query Metadata Input Validation for CreatePcj Key: RYA-214 URL: https://issues.apache.org/jira/browse/RYA-214 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Fix For: 3.2.10 When the method CreatePcj#withRyaIntegration is called, it creates the query metadata for Fluo and then populates Fluo with historical results form Rya. Before the metadata gets inserted, it's necessary to verify that the parsed query only consists of StatementPatterns, Joins, Leftjoins, Filters, and a Projection -- these are the only nodes that currently have observers implemented. Right now there is a visitor which attempts to verify this -- it has a meet method for each of the allowed node types -- but it has no meet method for other node types that are not allowed so it just skips these nodes. So in effect, for a given query, this visitor goes through and creates metadata only for nodes that are allowed in Fluo, and ignores invalid nodes. The bug here is that if the user attempts to insert a query with an invalid query node into Fluo, this method will insert a different query into Fluo (the query obtained from the original by removing the invalid nodes). The input validation visitor should traverse the query, creating metadata, and either insert all of the metadata if the visitor traverses the entire query without encountering an invalid node, or throw an exception if an invalid node is an encountered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-154) Decouple Configuration for Using PCJs and Using PCJ updater
Caleb Meier created RYA-154: --- Summary: Decouple Configuration for Using PCJs and Using PCJ updater Key: RYA-154 URL: https://issues.apache.org/jira/browse/RYA-154 Project: Rya Issue Type: Bug Components: clients, dao Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Fix For: 3.2.10 When a user configures a Rya Client to use Precomputed Joins for querying, it also adds the PrecomputedJoinIndexer to the list of additional indices. This should not be the case as the PrecomputedJoinIndexer is used to incrementally update PCJs as data is ingested, while enabling PCJs is a query client feature that can be used to boost query performance. Given the different roles of these two features, their configuration should be decoupled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-153) PCJ Matching Bug
Caleb Meier created RYA-153: --- Summary: PCJ Matching Bug Key: RYA-153 URL: https://issues.apache.org/jira/browse/RYA-153 Project: Rya Issue Type: Bug Components: clients Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Caleb Meier Fix For: 3.2.10 There is a bug in how the PCJOptimizer matches PCJs to sub-queries. As it's currently implemented, the PCJOptimizer decomposes queries into JoinSegments (portions of the query which contain only Joins) and LeftJoinSegments (portions of the query which contain Joins and LeftJoins). Each of these segment types has an associated matcher (JoinSegmentMatcher and LeftJoinSegmentMatcher) which performs the task of matching the PCJ queries to sub-queries of the respective segment. The JoinSegmentMatcher currently attempts to match the PCJs with LeftJoins to some sub-query of that segment. From an optimization point of view, it shouldn't attempt this match given that the PCJ contains LeftJoins and the JoinSegment doesn't (a match will never occur). But because the JoinSegmentMatcher isn't designed to handle LeftJoins, there is also buggy matching behavior occurring. So there needs to be some sort of input validation for the JoinSegmentMatcher to prevent the attempted match of a PCJ with LeftJoins to a JoinQuerySegment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RYA-148) Normalize Column Visibilities in Fluo Table
Caleb Meier created RYA-148: --- Summary: Normalize Column Visibilities in Fluo Table Key: RYA-148 URL: https://issues.apache.org/jira/browse/RYA-148 Project: Rya Issue Type: Bug Components: dao Affects Versions: 3.2.10 Reporter: Caleb Meier Assignee: Kevin Chilton Priority: Critical Fix For: 3.2.10 There is currently a bug in how the Rya Fluo Application handles column visibilities which leads to duplicate results in the Precomputed Join Tables. For example, consider a query that consists of a join which has StatementsPattern SP1 as a left arg and StatementPattern SP2 as a right arg. Suppose that a triple T1 comes in that matches SP1 and a triple T2 comes in that matches SP2. Also assume that T1 has visibility v1 and T2 has visibility v2. When the StatementPatternObserver processes T1, it joins the binding set associated with T1 (with visibility v1) with the binding set associated with T2 (with visibility v2). The result of the join is a binding set with visibility v1&v2. On the other hand, when the StatementPatternObserver processes T2, it produces the same binding set BS, but with visibility v2&v1. That is, the visibility of the StatementPattern bindingset being processed always comes first in the composite visibility formed from the join. This results in two copies of BS with the same visibility (just ordered differently). As a proposed fix, the visibilities should be combined in a manner consistent with how the StatementPatterns are ordered in the query. For example, always put the visibility of the left argument of the join first when forming the combined visibility. This will generate a default ordering of the composite visibility that won't lead to duplicates. In the above example, BS will have visibility v1&v2 regardless of whether T1 or T2 is processed first and the second copy that gets generated will overwrite the first, leading to no duplicate values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-98) InferenceEngine Configuration Issue in RyaDirectExample
[ https://issues.apache.org/jira/browse/RYA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-98. Resolution: Fixed > InferenceEngine Configuration Issue in RyaDirectExample > --- > > Key: RYA-98 > URL: https://issues.apache.org/jira/browse/RYA-98 > Project: Rya > Issue Type: Bug > Components: sail >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier >Priority: Minor > Fix For: 3.2.10 > > > Rya is currently configured to use inferencing by default. This shouldn't be > the case. Also, RyaDirectExample is not terminating because it creates an > instance of a SailRepository and a SailRepositoryConnection that it does not > close. By not closing the repository or the connection, the inference > engine, which is being created by default, does not get closed and the TImer > object within the Inference Engine causes the thread to be orphaned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RYA-115) Add Batch job commands to the Admin Shell
[ https://issues.apache.org/jira/browse/RYA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-115: Description: Add commands to the Admin Shell run prospector and join selectivity batch jobs. Other batch options might include inconsistency detection and batch updates of PCJs. (was: Fill this out.) > Add Batch job commands to the Admin Shell > - > > Key: RYA-115 > URL: https://issues.apache.org/jira/browse/RYA-115 > Project: Rya > Issue Type: Sub-task > Components: clients >Affects Versions: 3.2.10 >Reporter: Andrew Smith >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add commands to the Admin Shell run prospector and join selectivity batch > jobs. Other batch options might include inconsistency detection and batch > updates of PCJs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RYA-118) Query Based RDD
[ https://issues.apache.org/jira/browse/RYA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier updated RYA-118: Description: Add Spark Support to Rya providing capability to create RDDs from Rya queries. In particular, develop a factory which creates RDDs based on user specified entity-centric queries or statement patterns. > Query Based RDD > --- > > Key: RYA-118 > URL: https://issues.apache.org/jira/browse/RYA-118 > Project: Rya > Issue Type: Sub-task > Components: clients >Reporter: Andrew Smith >Assignee: Caleb Meier > Fix For: 3.2.10 > > > Add Spark Support to Rya providing capability to create RDDs from Rya > queries. In particular, develop a factory which creates RDDs based on user > specified entity-centric queries or statement patterns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-105) Fluo Integration with Rya
[ https://issues.apache.org/jira/browse/RYA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-105. - Resolution: Fixed > Fluo Integration with Rya > - > > Key: RYA-105 > URL: https://issues.apache.org/jira/browse/RYA-105 > Project: Rya > Issue Type: Bug > Components: dao >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Fix For: 3.2.10 > > > The Fluo table for incrementally updating precomputed joins is not fully > integrated with Rya. The PrecomputedJoinIndexer (which is an implementation > of the AccumuloIndexer interface) is not being added to the list of indexers > when the PCJ flag is set. So the DAO is never adding to Fluo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-50) Add Support for Sparql Optional Statements in Precomputed Joins
[ https://issues.apache.org/jira/browse/RYA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-50. Resolution: Fixed > Add Support for Sparql Optional Statements in Precomputed Joins > --- > > Key: RYA-50 > URL: https://issues.apache.org/jira/browse/RYA-50 > Project: Rya > Issue Type: Improvement >Affects Versions: 3.2.10 >Reporter: Caleb Meier >Assignee: Caleb Meier > Original Estimate: 60h > Remaining Estimate: 60h > > Rya currently only supports Precomputed Joins for SPARQL queries consisting > of StatementPatterns, Joins, and Filters. The task is to extend Rya's > Precomputed Join capability to allow for queries that contain OPTIONAL > statements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (RYA-62) Query Optimization: Support more than one PCJ that has optional fields.
[ https://issues.apache.org/jira/browse/RYA-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Meier resolved RYA-62. Resolution: Fixed Fix Version/s: 3.2.10 > Query Optimization: Support more than one PCJ that has optional fields. > --- > > Key: RYA-62 > URL: https://issues.apache.org/jira/browse/RYA-62 > Project: Rya > Issue Type: New Feature >Reporter: Kevin Chilton >Assignee: Caleb Meier > Fix For: 3.2.10 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
