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