Hi Michael,
Hi Niclas,
On 11/22/2014 2:13 AM, Michael Hunger 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.
that's also the approach we are following in our unmanaged extension for
our (RDF-based) graph data model and RDF.
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()
We also experimented with the label-based approach (see [1]) for
identifying the node types of the RDF-based graph data model (to make
use of the schema index approach of neo4j) in an earlier stage of
development. However, we didn't notify any difference in performance,
when querying our data. Furthermore, the metadata model (the RDF-based
graph data model) get mixed with the content itself. In my mind, it's a
better design approach to "separate" both worlds a bit from each other,
i.e., to define clear parts in the property graph model where one can
find content data and where metadata about the content (e.g., whether
the node is a literal node or a resource node). So I prefer to utilise
node labels to assign resource types (as I guess that's what they are
design for (to assign classes, types, categories, universals)), instead
of meta data model node types*.
Cheers,
Bo
*) albeit, we also write rdf:type statements into the graph db (which
can cause super nodes and which doubles this part of the content data)
to guarantee the compatibility to RDF
[1]
https://github.com/dswarm/dswarm-graph-neo4j/blob/3121b05d7a2f7c66945eb3068f6fde993bea55ce/src/main/java/org/dswarm/graph/rdf/parse/nx/Neo4jRDFHandler.java
Michael
|(a {kind: "uri", value: "http://example.com <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]
<mailto:[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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "Neo4j" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/neo4j/M_lOoLU9F1g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected]
<mailto:[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.
