Do i need a jira ticket for changes to the Rya web site?
There is a broken link on the Rya web site and I'd like to push a fix for it. How do I do this? Do i need to create a jira ticker or is that just for source code changes? How do I submit a pull request for website changes?
Fwd: Do i need a jira ticket for changes to the Rya web site?
Jira issue created https://issues.apache.org/jira/browse/RYA-228 Pull request https://github.com/apache/incubator-rya-site/pull/1 Does this look proper? -- Forwarded message -- From: Puja Valiyil Date: Wed, Dec 14, 2016 at 11:41 AM Subject: Re: Do i need a jira ticket for changes to the Rya web site? To: dev@rya.incubator.apache.org I think a jira ticket and then add Adina as a watcher. She knows the process for updating (I'm not sure everyone has permissions but I might be wrong). Sent from my iPhone > On Dec 14, 2016, at 2:25 PM, John Smith wrote: > > There is a broken link on the Rya web site and I'd like to push a fix for > it. How do I do this? Do i need to create a jira ticker or is that just > for source code changes? How do I submit a pull request for website > changes?
select * where { s? p? o? } query
*I was looking to make RYA more SPARQL1.1 compliant by enabling the
capability to perform the following query*
*SELECT * { s? p? o? } *
*I found that this capability is already supported, it is simply disabled
( RYA-83 )Could someone
point me to where in the code it is disabled?I would be interested in
better understanding the reasons for disabling this capability. All that
is said in RYA-83 is that it would perform a full table scan. I suppose
that could be expensive. But just because a query is expensive is that
reason enough to prevent someone from issuing the query? What if the user
is willing to pay the cost of running an expensive query? What are your
thoughts?*
Re: select * where { s? p? o? } query
Thank you! I got it to work using your suggestion. Here is a pull request
with this capability (https://github.com/apache/incubator-rya/pull/136).
I just had to added this NullRowTriplePatternStrategy to RyaTripleContext
default triple pattern strategies, so that it is used :)
On Wed, Jan 4, 2017 at 9:21 AM, David Lotts wrote:
> The error is thrown here:
> rya/dao/accumulo.rya/src/main/java/org/apache/rya/accumulo/
> query/AccumuloRyaQueryEngine.java
> line 142
>
>strategy = ryaContext.retrieveStrategy(stmt);
> if (strategy == null) {
> throw new IllegalArgumentException("TriplePattern[" +
> stmt + "] not supported");
> }
>
> The strategy is TABLE_LAYOUT and the scan range.
> The TABLE_LAYOUT is which table it scans to match the statement pattern:
> SPO, POS, or OSP, and
> the scan range is a start and stop byte[] range for scanning that table.
>
> Try creating a new strategy and see where that takes you:
>
> 1. Copy class SpoWholeRowTriplePatternStrategy to
> NullRowTriplePatternStrategy,
>
> /rya.api/src/main/java/org/apache/rya/api/query/strategy/wholerow/
> SpoWholeRowTriplePatternStrategy.java
> 2. fix the handle() method so that it returns true for all null parameters,
> and
> 3. replace the defineRange() with this:
>
> defineRange(RyaURI, RyaURI, RyaType, RyaURI,
> RdfCloudTripleStoreConfiguration) {
> start = new Byte[] { /* empty array */ }; // Scan from the
> beginning of the Accumulo table.
> stop = LAST_BYTES;// Scan to the end, up through things
> beginning with 0xff.
> return new RdfCloudTripleStoreUtils.CustomEntry ByteRange>(TABLE_LAYOUT.SPO, new ByteRange(start, stop));
> }
>
> Then add a new instance of NullRowTriplePatternStrategy in method:
> org.apache.rya.api.resolver.RyaTripleContext.
> addDefaultTriplePatternStrategies(boolean)
>
> And your done!
> There might be some oddness about creating a range with an empty start
> array. Might be better to skip the range when creating the scanner.
> david.
>
> On Tue, Jan 3, 2017 at 4:01 PM, John Smith wrote:
>
> > *I was looking to make RYA more SPARQL1.1 compliant by enabling the
> > capability to perform the following query*
> >
> > *SELECT * { s? p? o? } *
> >
> >
> >
> >
> >
> > *I found that this capability is already supported, it is simply disabled
> > ( RYA-83 <https://issues.apache.org/jira/browse/RYA-83> )Could someone
> > point me to where in the code it is disabled?I would be interested in
> > better understanding the reasons for disabling this capability. All that
> > is said in RYA-83 is that it would perform a full table scan. I suppose
> > that could be expensive. But just because a query is expensive is that
> > reason enough to prevent someone from issuing the query? What if the
> user
> > is willing to pay the cost of running an expensive query? What are your
> > thoughts?*
> >
>
GraphXGraphGenerator Usage Help
I'm trying to use the GraphXGraphGenerator class but it is hard coded to use the EntityCentricIndex table by default. But this doesn't exist in Rya by default. Shouldn't this default to the SPO table? Or perhaps even better, be a configurable parameter? What is the purpose of the EntityCentricIndex ? How do I enable it?
Re: GraphXGraphGenerator Usage Help
I can run the example, but when I try to use a live instance of accumulo (1.8) it throws a ClassNotFoundException DocumentIndexIntersectingIterator.java. It seems like the GraphxGraphGenerator is built against Accumulo 1.6.4, and even the test doesn't seem to work if I bump it up to 1.8. I wonder if this is an issue with the latest version of Accumulo not being supported by Rya? I find it strange that Accumulo complains about not being able to find the DocumentIndexIntersectingIterator.java class since it is a Rya class and not an accumulo class.. do i need to install (some kind of) a Rya addon to Accumulo for this to work? On Mon, Jan 9, 2017 at 7:39 PM, Puja Valiyil wrote: > Hi John, > It's not possible to use the core Rya indices to support the graphx api-- > there is a requirement for uniqueness in vertices that is not possible to > support using the core indices. To support graphx efficiently, all of the > assertions on a node of the graph must be stored on a single accumulo row > (so you can guarantee all of the assertions will be stored on a single > accumulo tablet). The core Rya indices do not support this requirement, > but the entity centric index does. > There is a configuration parameter to enable the entity centric index. You > can see how to enable it by looking at the entity centric example in the > examples project-- let me know if you have trouble finding it. > > On Monday, January 9, 2017, John Smith wrote: > > > I'm trying to use the GraphXGraphGenerator class but it is hard coded to > > use the EntityCentricIndex table by default. But this doesn't exist in > Rya > > by default. Shouldn't this default to the SPO table? Or perhaps even > > better, be a configurable parameter? What is the purpose of the > > EntityCentricIndex ? How do I enable it? > > >
Re: Rya UI/Console?
http://hostname:port/web.rya/sparqlQuery.jsp On Wed, Jan 11, 2017 at 2:02 PM, Ly, Kiet wrote: > Does Rya has any UI to run SPARQL query? > > Confidentiality Notice:: This email, including attachments, may include > non-public, proprietary, confidential or legally privileged information. > If you are not an intended recipient or an authorized agent of an intended > recipient, you are hereby notified that any dissemination, distribution or > copying of the information contained in or transmitted with this e-mail is > unauthorized and strictly prohibited. If you have received this email in > error, please notify the sender by replying to this message and permanently > delete this e-mail, its attachments, and any copies of it immediately. You > should not retain, copy or use this e-mail or any attachment for any > purpose, nor disclose all or any part of the contents to any other person. > Thank you. >
rdf4j-workbench
I'd like to install rdf4j-workbench into tomcat9. I tried the steps as detailed in vagrant for tomcat7 but that didn't seem to work. I installed the create-RyaAccumuloSail.xsl and create.xsl (https://github.com/apache/ incubator-rya/blob/master/extras/vagrantExample/src/main/resources/create- RyaAccumuloSail.xsl) and the libs.. but I get the below error. java.lang.NullPointerException org.eclipse.rdf4j.workbench.commands.CreateServlet.getConfigTemplate( CreateServlet.java:153) org.eclipse.rdf4j.workbench.commands.CreateServlet.createRepositoryConfig( CreateServlet.java:120) org.eclipse.rdf4j.workbench.commands.CreateServlet.doPost( CreateServlet.java:65) org.eclipse.rdf4j.workbench.base.TransformationServlet. service(TransformationServlet.java:96) org.eclipse.rdf4j.workbench.base.AbstractServlet.service( AbstractServlet.java:125) org.eclipse.rdf4j.workbench.proxy.ProxyRepositoryServlet.service( ProxyRepositoryServlet.java:109) org.eclipse.rdf4j.workbench.proxy.WorkbenchServlet. service(WorkbenchServlet.java:213) org.eclipse.rdf4j.workbench.proxy.WorkbenchServlet.handleRequest( WorkbenchServlet.java:141) org.eclipse.rdf4j.workbench.proxy.WorkbenchServlet. service(WorkbenchServlet.java:109) org.eclipse.rdf4j.workbench.proxy.WorkbenchGateway. service(WorkbenchGateway.java:120) org.eclipse.rdf4j.workbench.base.AbstractServlet.service( AbstractServlet.java:125) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) org.eclipse.rdf4j.workbench.proxy.CacheFilter.doFilter(CacheFilter.java:62) org.eclipse.rdf4j.workbench.proxy.CookieCacheControlFilter.doFilter( CookieCacheControlFilter.java:53) After a little googling this error seems to be caused by a failure to template file (RyaAccumuloSail.ttl) as detailed here http://docs.rdf4j.org/server-workbench-console/#_repository_configuration_ templates_advanced. No such file is detailed in the vagrant configuration, and so it is possible that this template requirement is new to the latest version of rdf4j-workbench. Does my understanding make sense, or am I missing something? Does anyone have the workbench working with the latest version of rdf4j-wrokbench?
Deleting Records from EntityCentricIndex
I found that if I add a single triple to Rya with the EntityCentricIndex enabled, it will add two entries to the EntityCentricIndex. It looks like it stores the triple in the forms OPS and SPO (in the EntityCentricIndex table). When I delete this triple from Rya, I can no longer see these two entries in the EntityCentricIndex however, in the Accumulo web interface I can see that the table now has 4 entries. It seems as though it didn't actually delete those entries, it just added two more entries that state the other two are to be regarded as deleted. Is this correct? Are there really 4 entries in this table? Is it possible to scan for these from the Accumulo shell? Do I need special auths to see deleted values?
Re: Deleting Records from EntityCentricIndex
I figured out what was causing the web interface to show entries in a given table despite the fact that I deleted all of those entries. It is simply caused by Accumulo's compaction mechanism, or the lack there of. The delete command(s) is(are) held in memory until a compaction occurs after which these files are actually deleted and the values in the Accumulo web view are updated accordingly. ( http://accumulo.apache.org/1.6/accumulo_user_manual#_table_maintenance) On Thu, Jan 12, 2017 at 1:14 PM, John Smith wrote: > I found that if I add a single triple to Rya with the EntityCentricIndex > enabled, it will add two entries to the EntityCentricIndex. It looks like > it stores the triple in the forms OPS and SPO (in the EntityCentricIndex > table). When I delete this triple from Rya, I can no longer see these two > entries in the EntityCentricIndex however, in the Accumulo web interface I > can see that the table now has 4 entries. It seems as though it didn't > actually delete those entries, it just added two more entries that state > the other two are to be regarded as deleted. Is this correct? Are there > really 4 entries in this table? Is it possible to scan for these from the > Accumulo shell? Do I need special auths to see deleted values? >
JanusGraph
Google, IBM, Hortonworks, and other companies have just decided to back Janus Graph, a scalable Graph DB. It is essentially a continuation of Titan DB (if you are familiar with Titan). http://janusgraph.org/ I wonder if it would make sense to create an Accumulo backend implementation for Janus, and a SPARQL extension. Such additions would largely make Janus equivalent to Rya (less cell level security). As Janus already supports Casandra and since Casandra and Accumulo are rather similar, I imagine it wouldn't be too hard to do. Also there already exists a SPARQL extension for Titan, we would simply need to update and extend it for the latest version of Janus. What are your thoughts?
On Storing Rya Metadata in the rya_spo table.
When I perform a scan of the rya_spo table after adding a SINGLE triple, I
see that Rya adds TWO triples, the one I wanted to add and one denoting the
version of Rya. e.g.
rya_spo> scan
INSERT DATA {
. }
rya_spo> scan
http://acme.com/people/Mike\x00http://acme.com/actions/likes\x00http://acme.com/people/John\x01\x02
: []
urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/2012/05#version\x003.0.0\x01\x03
: []
I suppose keeping track of metadata about the version of Rya that was used
to persist data into Accumulo is useful, but shouldn't this metadata be
stored in a different table? (like a metadata table, or something?). I
imagine users will be surprised if triples they didn't add appear in their
store, and surprising users is a code smell. What are your thoughts?
Re: On Storing Rya Metadata in the rya_spo table.
This occurs when using the latest from git 3.2.11-SNAPSHOT. What commit
fixed this?
On Tue, Jan 17, 2017 at 9:50 AM, Chilton, Kevin
wrote:
> Newer versions of Rya use the Rya Details table to keep track of this sort
> of metadata.
>
> - Kevin
>
> -Original Message-
> From: benk...@gmail.com [mailto:benk...@gmail.com] On Behalf Of John Smith
> Sent: Tuesday, January 17, 2017 12:20 PM
> To: dev@rya.incubator.apache.org
> Subject: On Storing Rya Metadata in the rya_spo table.
>
> When I perform a scan of the rya_spo table after adding a SINGLE triple, I
> see that Rya adds TWO triples, the one I wanted to add and one denoting the
> version of Rya. e.g.
>
> rya_spo> scan
>
> INSERT DATA { <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=Qj2CE5OU2Kd7J_TI_vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= > <https://urldefense.
> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEBoTm9
> Oxo&e= > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= > . }
>
> rya_spo> scan
> https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.
> com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=Qj2CE5OU2Kd7J_TI_
> vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= \x00https://urldefense.
> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEBoTm9
> Oxo&e= \x00https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= \x01\x02
> : []
> urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/
> 2012/05#version\x003.0.0\x01\x03
> : []
>
>
> I suppose keeping track of metadata about the version of Rya that was used
> to persist data into Accumulo is useful, but shouldn't this metadata be
> stored in a different table? (like a metadata table, or something?). I
> imagine users will be surprised if triples they didn't add appear in their
> store, and surprising users is a code smell. What are your thoughts?
>
Rya GraphX vertexIds
When I use the GraphXGraphGenerator, to create an instance of a GraphXGraph which represents my Rya graph, it generates vertexID's by hashing the string value of the vertcies in the Rya store, but aren't hash functions one way? How am I suppose to know which vertex in GraphX corresponds to which vertex in Rya?
Re: On Storing Rya Metadata in the rya_spo table.
I can find it with this query
select * {
?p ?o .
}
I also get it when I load the graph into GraphX, since it pulls the entire
graph.
Being but a single triple it isn't a huge deal, but we are establishing the
precedent that metadata about the implementation details of our store is to
be intermixed with the users data, and intermixing user data with
implementation specific details seems like a bad idea. What if a
(malicious?) user wanted to store triples that talk about older versions of
Rya? They could insert the triple e.g.
INSERT DATA { "1.0.0" . }
And now our system would have the fact that it is both version 3.0.0 and
1.0.0. I imagine that could cause problems.
On Tue, Jan 17, 2017 at 1:18 PM, David Lotts wrote:
> >> When I perform a scan of the rya_spo table after adding a SINGLE triple,
> I
> >> see that Rya adds TWO triples, the one I wanted to add and one denoting
> the
> >> version of Rya. e.g.
>
> Can you see the triple via Sparql?
> This gets amplified now that we support "select * where {?s ?p ?o. }"
>
> Elsewhere, this is done with built-in functions:
>
> select ( system:version() )
>
> For example:
> https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/
> VirtCheckSvrVersionViaSparql
>
> Pro's:
> All the SQL databases that I know of have system metadata tables. You
> don't see them unless you specify the table name.
> Because SQL tables and RDF name spaces have some similarities, in the same
> way, metadata is scoped and out of the way of applications.
> Also inference gives you triples that you did not add. So it's a "don't
> ask for what you don't want" kind of assumption.
>
> But I'm not an authority.
>
> Code is here:
>
> https://github.com/apache/incubator-rya/blob/master/
> common/rya.api/src/main/java/org/apache/rya/api/domain/RyaSchema.java
>
> The subject: *urn:org.apache.rya/2012/05#*
> is not a valid URI. The possible strings that follow "urn:" are registered
> by IANA
> --
> the
> urn namespace. If you want to roll your own, use a URL (http:...) or a the
> "tag" URI scheme, described here: https://tools.ietf.org/html/rfc4151 .
> Tags look like this: *tag:rya.apache.org
> ,2017:details#version*
>
> david.
>
> On Tue, Jan 17, 2017 at 1:19 PM, Chilton, Kevin >
> wrote:
>
> > It was checked into 3.2.10. I don't recall if the Rya Details stuff is
> > enabled by default or if it works without using the rya shell to manage
> > your instance. I thought we had a jira ticket relating to version
> > statement, but I'm unable to find it.
> >
> > - Kevin
> >
>
Re: On Storing Rya Metadata in the rya_spo table.
Also if you have two instances of Rya (because your doing say A/B
development for example) and you upgrade one of them and then you want to
transfer the triples from the older version to the newer version, then you
would get the old version and the new version in your store.
Also if you have a Single Accumulo cluster, but multiple clients, if at any
point a user upgrades their client, and does a direct write to Accumulo,
instead of via the web API, then we would again have two (or more) versions
in our Rya Store.
Such are some of the difficulties with this scheme.
---
Kevin Chilton I think I see what you were talking about
AccumuloRyaInstanceDetailsRepository (
https://github.com/apache/incubator-rya/blob/master/dao/accumulo.rya/src/main/java/org/apache/rya/accumulo/instance/AccumuloRyaInstanceDetailsRepository.java
)
When I add data to Rya it runs through this class and throws a
TableNotFoundException.
So it would seem it most definitely is not enabled by default. Is there a
flag I need to set to enable it or something?
I'm thinking it would make sense to refactor the "rya_instance_details"
table into the "rya_meta_data" table and we add this to our
TableLayoutStrategy, that way we can create this table the same way we make
the other tables, and going forward we can say that we ought to push and
pull all our system specific meta data from there, and we could put in a
ticket to refactor our current codebase to be inline with this philosophy.
Would this make sense?
On Tue, Jan 17, 2017 at 1:52 PM, John Smith wrote:
> I can find it with this query
>
> select * {
> ?p ?o .
>
> }
>
>
> I also get it when I load the graph into GraphX, since it pulls the entire
> graph.
>
>
> Being but a single triple it isn't a huge deal, but we are establishing
> the precedent that metadata about the implementation details of our store
> is to be intermixed with the users data, and intermixing user data with
> implementation specific details seems like a bad idea. What if a
> (malicious?) user wanted to store triples that talk about older versions of
> Rya? They could insert the triple e.g.
>
> INSERT DATA { 05#version> "1.0.0" . }
>
> And now our system would have the fact that it is both version 3.0.0 and
> 1.0.0. I imagine that could cause problems.
>
>
>
> On Tue, Jan 17, 2017 at 1:18 PM, David Lotts wrote:
>
>> >> When I perform a scan of the rya_spo table after adding a SINGLE
>> triple,
>> I
>> >> see that Rya adds TWO triples, the one I wanted to add and one denoting
>> the
>> >> version of Rya. e.g.
>>
>> Can you see the triple via Sparql?
>> This gets amplified now that we support "select * where {?s ?p ?o. }"
>>
>> Elsewhere, this is done with built-in functions:
>>
>> select ( system:version() )
>>
>> For example:
>> https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/
>> VirtCheckSvrVersionViaSparql
>>
>> Pro's:
>> All the SQL databases that I know of have system metadata tables. You
>> don't see them unless you specify the table name.
>> Because SQL tables and RDF name spaces have some similarities, in the same
>> way, metadata is scoped and out of the way of applications.
>> Also inference gives you triples that you did not add. So it's a "don't
>> ask for what you don't want" kind of assumption.
>>
>> But I'm not an authority.
>>
>> Code is here:
>>
>> https://github.com/apache/incubator-rya/blob/master/common/
>> rya.api/src/main/java/org/apache/rya/api/domain/RyaSchema.java
>>
>> The subject: *urn:org.apache.rya/2012/05#*
>> is not a valid URI. The possible strings that follow "urn:" are
>> registered
>> by IANA
>> <http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml> --
>> the
>> urn namespace. If you want to roll your own, use a URL (http:...) or a
>> the
>> "tag" URI scheme, described here: https://tools.ietf.org/html/rfc4151 .
>> Tags look like this: *tag:rya.apache.org
>> <http://rya.apache.org>,2017:details#version*
>>
>> david.
>>
>> On Tue, Jan 17, 2017 at 1:19 PM, Chilton, Kevin <
>> kevin.chil...@parsons.com>
>> wrote:
>>
>> > It was checked into 3.2.10. I don't recall if the Rya Details stuff is
>> > enabled by default or if it works without using the rya shell to manage
>> > your instance. I thought we had a jira ticket relating to version
>> > statement, but I'm unable to find it.
>> >
>> > - Kevin
>> >
>>
>
>
Re: Timestamps and Cardinality in Queries
I have a pull request that fixes that problem.. it has been stuck in limbo
for months.. https://github.com/apache/incubator-rya-site/pull/1 Can
someone merge it into master?
On Thu, Feb 23, 2017 at 2:00 PM, Liu, Eric wrote:
> Cool, thanks for the help.
> By the way, the link to the Rya Manual is outdated on the rya.apache.org
> site. Should be pointing at https://github.com/apache/
> incubator-rya/blob/master/extras/rya.manual/src/site/markdown/_index.md
>
> On 2/23/17, 12:34 PM, "Aaron D. Mihalik" wrote:
>
> deep vs wide:
>
> A property path query is probably your best bet. Something like:
>
> for the following data:
>
> s:EventA p:causes s:EventB
> s:EventB p:causes s:EventC
> s:EventC p:causes s:EventD
>
>
> This query would start at EventB and work it's way up and down the
> chain:
>
> SELECT * WHERE {
> (|^)* ?s . ?s ?p ?o
> }
>
>
> On Thu, Feb 23, 2017 at 2:58 PM Meier, Caleb
> wrote:
>
> > Yes, that's a good place to start. If you have external timestamps
> that
> > are built into your graph using the time ontology in owl (e.g you
> have
> > triples of the form (event123, time:inDateTime, 2017-02-23T14:29)),
> the
> > temporal index is exactly what you want. If you are hoping to query
> based
> > on the internal timestamps that Accumulo assigns to your triples,
> then
> > there are some slight tweaks that can be done to facilitate this,
> but it
> > won't be nearly as efficient (this will require some sort of client
> side
> > filtering).
> >
> > Caleb A. Meier, Ph.D.
> > Software Engineer II ♦ Analyst
> > Parsons Corporation
> > 1911 N. Fort Myer Drive, Suite 800 ♦ Arlington, VA 22209
> > Office: (703)797-3066 <(703)%20797-3066>
> > caleb.me...@parsons.com ♦ www.parsons.com
> >
> > -Original Message-
> > From: Liu, Eric [mailto:eric@capitalone.com]
> > Sent: Thursday, February 23, 2017 2:27 PM
> > To: dev@rya.incubator.apache.org
> > Subject: Re: Timestamps and Cardinality in Queries
> >
> > We’d like to be able to query by timestamp; specifically, we want to
> be
> > able to find all statements that were made within a given time
> range. Is
> > this what I should be looking at?
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.
> apache.org_confluence_download_attachments_63407907_
> Rya-2520Temporal-2520Indexing.pdf-3Fversion-3D1-26modificationDate-
> 3D1464789502000-26api-3Dv2&d=CwIGaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m=
> BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw&s=vLayAkLG0IKGE-
> 0NbwRQKfpcfId05fXE5TX8oMJaa7Q&e=
> >
> >
> >
> > On 2/22/17, 6:21 PM, "Meier, Caleb" wrote:
> >
> >
> >
> > Hey Eric,
> >
> >
> >
> > Currently timestamps can't be queried in Rya. Do you need to be
> able
> > to query by timestamp, or simply discover the timestamp for a given
> node?
> > Rya does have a temporal index, but that requires you to use a
> temporal
> > ontology to model the temporal properties of your graph nodes.
> >
> >
> >
> > From: Liu, Eric
> >
> > Sent: Wednesday, February 22, 2017 6:38 PM
> >
> > To: dev@rya.incubator.apache.org
> >
> > Subject: Timestamps and Cardinality in Queries
> >
> >
> >
> > Hi,
> >
> >
> >
> > Continuing from our talk earlier today I was wondering if you
> could
> > provide more information about how timestamps could be queried in
> Rya.
> >
> > Also, we are trying to support a type of query that would
> essentially
> > be limiting on cardinality (different from the normal SPARQL limit
> because
> > it’s for node cardinality rather than total results). I saw in one of
> > Caleb’s talks that Rya’s query optimization involves checking
> cardinality
> > first. I was wondering if there would be some way to tap into this
> feature
> > for usage in queries?
> >
> >
> >
> > Thanks,
> >
> > Eric Liu
> >
> >
> >
> >
> >
> > The information contained in this e-mail is confidential and/or
> > proprietary to Capital One and/or its affiliates and may only be used
> > solely in performance of work or services for Capital One. The
> information
> > transmitted herewith is intended only for use by the individual or
> entity
> > to which it is addressed. If the reader of this message is not the
> intended
> > recipient, you are hereby notified that any review, retransmission,
> > dissemination, distribution, copying or other use of, or taking of
> any
> > action in reliance upon this information is strictly prohibited. If
> you
> > have received t
