Andy, On Tue, Nov 10, 2015 at 4:08 PM, Andy Seaborne <[email protected]> wrote:
> On 10/11/15 20:13, Juan Sequeda wrote: > >> Andy, >> >> On Tue, Nov 10, 2015 at 3:06 AM, Andy Seaborne <[email protected]> wrote: >> >> On 10/11/15 03:25, Juan Sequeda wrote: >>> >>> Rob, all >>>> >>>> The query does work for my needs. Thanks! >>>> >>>> Each Tree graph will consist of 10-20 triples for a given root. Given >>>> those >>>> circumstances, what do you think performance would be? >>>> >>>> As I mentioned, another idea is to put the RDF graph in a NG and then >>>> just >>>> clear that NG. >>>> >>>> What is the experience of using a high number of Named Graphs with small >>>> number of triples in each named graph (~10-20 triples). The >>>> operations/queries I am expecting to do are: >>>> >>>> - Given a root, return me the tree graph associated to that root >>>> CONSTRUCT {?s ?p ?o} { GRAPH <http://example/> { ?s ?p ?o } } >>>> >>>> - Given a root, delete the tree graph associated to that root. >>>> CLEAR GRAPH <http://example/> >>>> >>>> - Insert a graph >>>> INSERT DATA { GRAPH <http://example/> { ... } } >>>> >>>> Thanks for the pointers. >>>> >>>> >>> Hi Juan, >>> >>> Exact details depend on the backend. I guess you wil then use default >>> union graph to query all the NG's as one? >>> >>> >> In my case, I do not need to query all the NGs at once. My query workload >> will always have the NG uri. >> >> >>> For the current general purpose in-memory dataset, GRAPH ?g is a loop as >>> would be a default union graph, so huge numbers may be an issue for query >>> over all graphs, but of course it's in-memory so limited in scale anyway. >>> >>> For TDB, a graph name is just a column and default union graph should be >>> as fast. >>> >>> >> I am using TDB. So looks like I'm ok. >> >> >> >>> For new fully transactional dataset, not yet released (JENA-624), the >>> design allows for default union graph in a manner similar to TDB. >>> >> >> >> Cool to know. >> >> Btw, in your opinion, what would be the best way to go? Use the SPARQL >> property path query that Rob suggested or use the NG approach? I'd truly >> appreciate your insight. >> > > Personal opinion - the Graph Store Protocol is a great way to manage the > dataset. That's the NG way + using the HTTP verbs to PUT (replace), POST > (append) and DELETE graphs. > > There is an equivalence between GSP and certain SPARQL Update management > operations so choose the way that fits your workflow. > > The one point to recognize is that a dataset can only use named graph for > one thing. And we onyl have quads ... not quintuples or more. Thats the thing. I now have many quads to keep track of and ideally I would like to group a set of quads together (create a forest). This would be possible easily with quintuples. Now, I need to make another NG which is going to consist of a list of all the NGs that should be together. In the other approach, I would use a NG as a container for all the RDF treegraphs, basically the NG would be the forest. I appreciate your opinion. > > > Andy > > > >> Thanks! >> >> >> >>> >>> Andy >>> >>> >>> >>> >>>> >>>> -- >>>> Juan Sequeda, Ph.D >>>> +1-575-SEQ-UEDA >>>> www.juansequeda.com >>>> >>>> On Mon, Nov 9, 2015 at 6:12 PM, Rob Vesse <[email protected]> wrote: >>>> >>>> Juan >>>> >>>>> >>>>> I haven't tested this but in principal the following should work: >>>>> >>>>> DELETE >>>>> { >>>>> ?s ?p ?o >>>>> } >>>>> WHERE >>>>> { >>>>> { >>>>> # Find things directly connected to the root >>>>> <root> ?p ?o . >>>>> BIND(<root> AS ?s) >>>>> } >>>>> UNION >>>>> { >>>>> # Find everything indirectly connected to the root >>>>> <root> (<>|!<>)+ ?s . >>>>> ?s ?p ?o . >>>>> } >>>>> } >>>>> >>>>> In the first branch simply select any triples directly off of the root. >>>>> In the second branch find any triples one/more steps away from the root >>>>> and the associated triples. Then in the DELETE template simply delete >>>>> all >>>>> the matched triples. >>>>> >>>>> The second branch uses Joshua Taylor's trick from >>>>> http://stackoverflow.com/a/26707541/107591 of using a property path >>>>> via >>>>> a >>>>> URI and its negation to find any subject that is reachable by 1 or more >>>>> steps via any property from your root. You can then simply grab things >>>>> that are directly connected to that subject. >>>>> >>>>> This will probably perform badly and can be sped up if you have a >>>>> specific >>>>> property used to denote the tree hierarchy. For example if the root is >>>>> linked to child nodes via the property :child then we could rewrite the >>>>> second branch as follows: >>>>> >>>>> <root> :child+ ?s . >>>>> ?s ?p ?o . >>>>> >>>>> Which still requires a property path but will perform better because >>>>> the >>>>> path is simpler. >>>>> >>>>> Rob >>>>> >>>>> On 09/11/2015 15:32, "Charles Greer" <[email protected]> >>>>> wrote: >>>>> >>>>> Hi Juan, >>>>> >>>>>> >>>>>> Seems that if you can do this efficiently >>>>>> >>>>>> "Another thought is to put the RDF graph in a NG and then just clear >>>>>> the >>>>>> NG." >>>>>> >>>>>> then that will be more efficient than following property paths. >>>>>> >>>>>> Interesting question to be sure. >>>>>> >>>>>> Charles >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: Juan Sequeda [[email protected]] >>>>>> Sent: Monday, November 09, 2015 3:28 PM >>>>>> To: [email protected] >>>>>> Subject: Deleting an entire RDF graph >>>>>> >>>>>> All, >>>>>> >>>>>> Assume I have an RDF graph which is a tree, hence there is a root >>>>>> node. >>>>>> What is the best way of deleting that entire RDF graph given the root >>>>>> node? >>>>>> >>>>>> Is there a way to do it with Property paths? And if so, I guess I >>>>>> would >>>>>> have to have knowledge of the structure of the graph/tree? >>>>>> >>>>>> Another thought is to put the RDF graph in a NG and then just clear >>>>>> the >>>>>> NG. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Juan >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
