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" <[email protected]> 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:EventB> (<p:causes>|^<p:causes>)* ?s . ?s ?p ?o } On Thu, Feb 23, 2017 at 2:58 PM Meier, Caleb <[email protected]> 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> > [email protected] ♦ www.parsons.com > > -----Original Message----- > From: Liu, Eric [mailto:[email protected]] > Sent: Thursday, February 23, 2017 2:27 PM > To: [email protected] > 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" <[email protected]> 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 <[email protected]> > > Sent: Wednesday, February 22, 2017 6:38 PM > > To: [email protected] > > 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 this communication in error, please contact the sender and > delete the material from your computer. > > > > > > > > ________________________________________________________ > > > > 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 this communication in error, please contact the sender and > delete the material from your computer. > ________________________________________________________ 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 this communication in error, please contact the sender and delete the material from your computer.
