Hmm, taking a look at the code it seems you use Tinkerpop GraphSail, as that implementation doesn't support labels or probably better representation of rdf as property-graph I wonder what it would take to rewrite GraphSail as part of this extension to properly support the Neo4j property graph model.
I think you should be able to get the size requirements down to a minimal level and performance up a lot. On Sat, Nov 22, 2014 at 3:05 AM, Michael Hunger < [email protected]> wrote: > Niclas, do you have the perf tests as part of the repository? > > On Sat, Nov 22, 2014 at 2:13 AM, Michael Hunger < > [email protected]> wrote: > >> Hey Niclas, when looking at your post, I wondered how you do your cypher >> query and thought you could easily speed up performance by a factor of 100 >> or 1000 >> >> look at these nodes -> if you added the "kind" as a label to each node, >> like :Uri, :Literal, :BNode and then created an index on :Label(value) for >> each of those. >> You could even leave off the "kind" properties then. >> >> Alternatively for a quick win you can add a "generic" label, like ":Node" >> and create an index on :Node(value) >> >> Then (depending on the way you resolve things in your sparql impl, you >> should be able to speed it up massively, by using the label + value to find >> things (either via cypher or embedded api (graphdb.findByLabelAndProperty() >> >> Michael >> >> (a {kind: "uri", value: "http://example.com"; }) >> A literal node: >> (a {kind: "literal", value: "Text", type: " >> http://www.w3.org/2001/XMLSchema#"}) >> A blank node: >> (a {kind: "bnode" value: "genid--b1234"}) >> >> >> On Sat, Nov 22, 2014 at 2:10 AM, Andrii Stesin <[email protected]> wrote: >> >>> Hi Bo, >>> >>> yes it definitely has something in common. Would you please mind >>> pointing me to some explanations, why reification is considered so harmful? >>> >>> I see some interesting points there, namely >>> >>> The subject of a reification >>>> <http://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#dfn-reification> is >>>> intended to refer to a concrete realization of an RDF triple, such as a >>>> document in a surface syntax, rather than a triple considered as an >>>> abstract object. This *supports use cases where properties such as >>>> dates of composition or provenance information are applied to the reified >>>> triple*, which are meaningful *only when thought of as referring to a >>>> particular instance* or token of a triple. >>> >>> >>> it seems worth the attention at the very least. And also >>> >>> Since the relation between triples and reification >>>> <http://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#dfn-reification>s of >>>> triples in any RDF graph or graphs need not be one-to-one, asserting a >>>> property about some entity described by a reification >>>> <http://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#dfn-reification> >>>> need not entail that the same property holds of another such entity, even >>>> if it has the same components. >>> >>> >>> This seems interesting to me. Also I like dictionary approach like in RDF >>> HDT format <http://www.rdfhdt.org/technical-specification/#triples>. >>> What do you think about this combination as a basic data model? >>> >>> WBR, >>> Andrii >>> >>> On Saturday, November 22, 2014 12:12:16 AM UTC+2, Bo Ferri wrote: >>>> >>>> Hi Andrii, >>>> well, this looks like a re-incarnation of RDF reification [1], which is >>>> the worst modelling option for subject-predicate-object statements in >>>> my >>>> mind ;) >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
