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 <[email protected]> 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 <[email protected]> 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" <[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. >>
