Re: Timestamps and Cardinality in Queries
> >>>
> > > > >>> Sent from my iPhone
> > > > >>>
> > > > >>>> On Feb 23, 2017, at 8:13 PM, John Smith <
> > johns0...@gmail.com>
> > > wrote:
> > > > >>>>
> > > > >>>> 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 <
> > > eric@capitalone.com>
> > > > >>> 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" <
> > > aaron.miha...@gmail.com>
> > > > >>> 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 <
> > > > >>> caleb.me...@parsons.com>
> > > > >>>>> 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
Re: Timestamps and Cardinality in Queries
gt; > > > > >Eric: Could you clarify by "deep vs wide"? I think > I > > > understand your > > > > >queries, but I don't have a good intuition about > those > > terms > > > and how > > > > >cardinality might figure into a query. It would > probably > > be a > > > bit > > > > more > > > > >helpful if you provided a model or general > description > > that is > > > > (somewhat) > > > > >representative of your data. > > > > > > > > > >--Aaron > > > > > > > > > >[1] > > > > > > > > > > > > > > > https://github.com/amihalik/sesame-debugging/blob/master/src/main/java/com/github/amihalik/sesame/debugging/PropertyPathsExample.java > > > > > > > > > >>On Thu, Feb 23, 2017 at 9:42 PM Adina Crainiceanu < > > > ad...@usna.edu> > > > > wrote: > > > > >> > > > > >> Hi Eric, > > > > >> > > > > >> If you want to query by the Accumulo timestamp, > something > > like > > > > >> timeRange(?ts, 13141201490, 13249201490) should work > in > > Rya. I > > > did not > > > > try > > > > >> it lately, but timeRange() was in Rya originally. Not > sure > > if it > > > was > > > > >> removed in later iterations or whether it would be > useful > > for > > > your use > > > > >> case. First Rya paper > > > > >> > > https://www.usna.edu/Users/cs/adina/research/Rya_CloudI2012.pdf > > > > discusses > > > > >> time ranges (Section 5.3 at the link above) > > > > >> > > > > >> Adina > > > > >> > > > > >>> On Thu, Feb 23, 2017 at 8:31 PM, Puja Valiyil < > > puja...@gmail.com > > > > > > > > wrote: > > > > >>> > > > > >>> Hey John, > > > > >>> I'm pretty sure your pull request was merged-- it was > > pulled in > > > through > > > > >>> another pull request. If not, sorry-- I thought it > had > > been > > > merged and > > > > >>> then just not closed. I was going to spend some > time doing > > > merges > > > > >> tomorrow > > > > >>> so I can get it tomorrow. > > > > >>> > > > > >>> Sent from my iPhone > > > > >>> > > > > >>>> On Feb 23, 2017, at 8:13 PM, John Smith < > > johns0...@gmail.com> > > > wrote: > > > > >>>> > > > > >>>> 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 < > > > eric@capitalone.com> > > > > >>> 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/
Re: Timestamps and Cardinality in Queries
row (3/1). > > > > > > Thanks, > > > Eric > > > > > > On 2/24/17, 6:18 AM, "Aaron D. Mihalik" <aaron.miha...@gmail.com> > wrote: > > > > > >deep vs wide: I played around with the property paths sparql > operator > > and > > >put up an example here [1]. This is a slightly different query > than > > the > > >one I sent out before. It would be worth it for us to look at > how > > this is > > >actually executed by OpenRDF. > > > > > >Eric: Could you clarify by "deep vs wide"? I think I > understand your > > >queries, but I don't have a good intuition about those terms > and how > > >cardinality might figure into a query. It would probably be a > bit > > more > > >helpful if you provided a model or general description that is > > (somewhat) > > >representative of your data. > > > > > >--Aaron > > > > > >[1] > > > > > > https://github.com/amihalik/sesame-debugging/blob/master/src/main/java/com/github/amihalik/sesame/debugging/PropertyPathsExample.java > > > > > >>On Thu, Feb 23, 2017 at 9:42 PM Adina Crainiceanu < > ad...@usna.edu> > > wrote: > > >> > > >> Hi Eric, > > >> > > >> If you want to query by the Accumulo timestamp, something like > > >> timeRange(?ts, 13141201490, 13249201490) should work in Rya. I > did not > > try > > >> it lately, but timeRange() was in Rya originally. Not sure if it > was > > >> removed in later iterations or whether it would be useful for > your use > > >> case. First Rya paper > > >> https://www.usna.edu/Users/cs/adina/research/Rya_CloudI2012.pdf > > discusses > > >> time ranges (Section 5.3 at the link above) > > >> > > >> Adina > > >> > > >>> On Thu, Feb 23, 2017 at 8:31 PM, Puja Valiyil <puja...@gmail.com > > > > wrote: > > >>> > > >>> Hey John, > > >>> I'm pretty sure your pull request was merged-- it was pulled in > through > > >>> another pull request. If not, sorry-- I thought it had been > merged and > > >>> then just not closed. I was going to spend some time doing > merges > > >> tomorrow > > >>> so I can get it tomorrow. > > >>> > > >>> Sent from my iPhone > > >>> > > >>>> On Feb 23, 2017, at 8:13 PM, John Smith <johns0...@gmail.com> > wrote: > > >>>> > > >>>> 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 < > eric@capitalone.com> > > >>> 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" < > aaron.miha...@gmail.com> > > >>> 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 > > >>&
Re: Timestamps and Cardinality in Queries
cusses
> >> time ranges (Section 5.3 at the link above)
> >>
> >> Adina
> >>
> >>> On Thu, Feb 23, 2017 at 8:31 PM, Puja Valiyil <puja...@gmail.com>
> wrote:
> >>>
> >>> Hey John,
> >>> I'm pretty sure your pull request was merged-- it was pulled in through
> >>> another pull request. If not, sorry-- I thought it had been merged and
> >>> then just not closed. I was going to spend some time doing merges
> >> tomorrow
> >>> so I can get it tomorrow.
> >>>
> >>> Sent from my iPhone
> >>>
> >>>> On Feb 23, 2017, at 8:13 PM, John Smith <johns0...@gmail.com> wrote:
> >>>>
> >>>> 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 <eric@capitalone.com>
> >>> 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" <aaron.miha...@gmail.com>
> >>> 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 <
> >>> caleb.me...@parsons.com>
> >>>>> 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> <(703)%20797-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?
> >>>
Re: Timestamps and Cardinality in Queries
dex.md
>>>>>
>>>>> On 2/23/17, 12:34 PM, "Aaron D. Mihalik" <aaron.miha...@gmail.com>
>>> 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 <
>>> caleb.me...@parsons.com>
>>>>> 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> <(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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_
>>>>> LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC
>>> geo_4WXTD0qo8=
>>>>> BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE-
>>>>> 0NbwRQKfpcfId05fXE5TX8oMJaa7Q=
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric@capitalone.com>
>>>>>>
>>>>>> Sent: Wednesday, February 22, 2017 6:38 PM
>>>>>>
>>>>>> To: dev@rya.incubator.apache.org
>>>>>>
>>>>>> Subject: Timestamps and Cardinality in Queries
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Re: Timestamps and Cardinality in Queries
> > >> > > >>> 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> <(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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_ > > >> LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC > > geo_4WXTD0qo8= > > >> BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE- > > >> 0NbwRQKfpcfId05fXE5TX8oMJaa7Q= > > >>> > > >>> > > >>> > > >>> On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric@capitalone.com> > > >>> > > >>>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
Re: Timestamps and Cardinality in Queries
deep vs wide: I played around with the property paths sparql operator and
put up an example here [1]. This is a slightly different query than the
one I sent out before. It would be worth it for us to look at how this is
actually executed by OpenRDF.
Eric: Could you clarify by "deep vs wide"? I think I understand your
queries, but I don't have a good intuition about those terms and how
cardinality might figure into a query. It would probably be a bit more
helpful if you provided a model or general description that is (somewhat)
representative of your data.
--Aaron
[1]
https://github.com/amihalik/sesame-debugging/blob/master/src/main/java/com/github/amihalik/sesame/debugging/PropertyPathsExample.java
On Thu, Feb 23, 2017 at 9:42 PM Adina Crainiceanu <ad...@usna.edu> wrote:
> Hi Eric,
>
> If you want to query by the Accumulo timestamp, something like
> timeRange(?ts, 13141201490, 13249201490) should work in Rya. I did not try
> it lately, but timeRange() was in Rya originally. Not sure if it was
> removed in later iterations or whether it would be useful for your use
> case. First Rya paper
> https://www.usna.edu/Users/cs/adina/research/Rya_CloudI2012.pdf discusses
> time ranges (Section 5.3 at the link above)
>
> Adina
>
> On Thu, Feb 23, 2017 at 8:31 PM, Puja Valiyil <puja...@gmail.com> wrote:
>
> > Hey John,
> > I'm pretty sure your pull request was merged-- it was pulled in through
> > another pull request. If not, sorry-- I thought it had been merged and
> > then just not closed. I was going to spend some time doing merges
> tomorrow
> > so I can get it tomorrow.
> >
> > Sent from my iPhone
> >
> > > On Feb 23, 2017, at 8:13 PM, John Smith <johns0...@gmail.com> wrote:
> > >
> > > 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 <eric@capitalone.com>
> > 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" <aaron.miha...@gmail.com>
> > 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 <
> > caleb.me...@parsons.com>
> > >>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> <(703)%20797-3066>
> > >>> caleb.me...@parsons.com ♦ www.parsons.com
> > >>>
> > >>> -Original Message-
> > >>> From: Liu, Eric [mailto:eric@capitalone.com]
> > >>> Sent: Thursday, February 23,
Re: Timestamps and Cardinality in Queries
Hi Eric,
If you want to query by the Accumulo timestamp, something like
timeRange(?ts, 13141201490, 13249201490) should work in Rya. I did not try
it lately, but timeRange() was in Rya originally. Not sure if it was
removed in later iterations or whether it would be useful for your use
case. First Rya paper
https://www.usna.edu/Users/cs/adina/research/Rya_CloudI2012.pdf discusses
time ranges (Section 5.3 at the link above)
Adina
On Thu, Feb 23, 2017 at 8:31 PM, Puja Valiyil <puja...@gmail.com> wrote:
> Hey John,
> I'm pretty sure your pull request was merged-- it was pulled in through
> another pull request. If not, sorry-- I thought it had been merged and
> then just not closed. I was going to spend some time doing merges tomorrow
> so I can get it tomorrow.
>
> Sent from my iPhone
>
> > On Feb 23, 2017, at 8:13 PM, John Smith <johns0...@gmail.com> wrote:
> >
> > 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 <eric@capitalone.com>
> 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" <aaron.miha...@gmail.com>
> 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 <
> caleb.me...@parsons.com>
> >>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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_
> >> LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC
> geo_4WXTD0qo8=
> >> BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE-
> >> 0NbwRQKfpcfId05fXE5TX8oMJaa7Q=
> >>>
> >>>
> >>>
> >>> On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> wrote:
> >>>
> >>>
> >>>
> >>>Hey Eric,
> >>>
> >>>
> >>>
> >>>Currently timestamps can't be queried in Rya
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 <eric@capitalone.com> 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" <aaron.miha...@gmail.com> 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 <caleb.me...@parsons.com>
> 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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=
> BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE-
> 0NbwRQKfpcfId05fXE5TX8oMJaa7Q=
> >
> >
> >
> > On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric@capitalone.com>
> >
> > 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
>
Re: Timestamps and Cardinality in Queries
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" <aaron.miha...@gmail.com> 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 <caleb.me...@parsons.com>
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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE-0NbwRQKfpcfId05fXE5TX8oMJaa7Q=
>
>
>
> On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric....@capitalone.com>
>
> 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 this communication in error, please contact the sender and
> delete
Re: Timestamps and Cardinality in Queries
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 <caleb.me...@parsons.com>
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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE-0NbwRQKfpcfId05fXE5TX8oMJaa7Q=
>
>
>
> On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric....@capitalone.com>
>
> 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 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.
>
RE: Timestamps and Cardinality in Queries
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
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=CwIGaQ=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=BBheKpKX7A1Ijs8q_TDEUVtdfu-r015XHZjmcw6veAw=vLayAkLG0IKGE-0NbwRQKfpcfId05fXE5TX8oMJaa7Q=
On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric@capitalone.com>
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 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.
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://cwiki.apache.org/confluence/download/attachments/63407907/Rya%20Temporal%20Indexing.pdf?version=1=1464789502000=v2
On 2/22/17, 6:21 PM, "Meier, Caleb" <caleb.me...@parsons.com> 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 <eric@capitalone.com>
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 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.
Re: Timestamps and Cardinality in Queries
I put up a "limit per node" example here [1] and Rya behaves as I expected. Strangely, OpenRDF does not :/ Unfortunately, the join between the two inner "SELECT" statements is not the more efficient MultipleBindingSetsIterator. Instead, the join is the less efficient OpenRDF Join. --Aaron [1] https://github.com/amihalik/sesame-debugging/blob/6a26045d89ebee1c72cc0452e2b01dc29544b85c/src/main/java/com/github/amihalik/sesame/debugging/NodeLimitExample.java On Wed, Feb 22, 2017 at 9:24 PM Meier, Caleb <caleb.me...@parsons.com> 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 <eric@capitalone.com> > 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 this communication in error, please contact the sender and > delete the material from your computer. >
