Re: [Neo4j] Properties vs. Relations

[Jim Webber]

Hi Gary,

The way you set up the question on properties vs relationships doesn't fit naturally for me, they're different things for different purposes.

Properties are the data that an entity like a node holds*. Relationships simply form the semantic glue (type, direction, cardinality) between nodes.

Jim

* relationships can also have properties so they're useful for things like weighted graph walks - this is difficult in RDF.

[Mark Needham]

I wrote a blog post a few months ago where I show how sometimes making what you might initially think is a property a relationship can allow you to write some more interesting queries more easily - http://www.markhneedham.com/blog/2013/03/06/neo4j-make-properties-relationships/

--
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 neo4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gary Schiltz]

Okay, I think I get it. Just to expand your response a bit, nodes/entities are basically a structuring mechanism for named atomic pieces of data (i.e. properties) related to each other, much like objects with data members in OOP, or structures with named fields in non-OOP languages (e.g. C structs or Pascal records). Relations are similar to named properties of a node, in that they "point to" some more data that is related to a given node, but unlike properties that refer to atomic data, a relationship refers to another node. As a bonus, a relationship can also have properties.

In RDF, a node (resource) is also related to named atomic data items through properties (predicates) and to non-atomic data (other resources) through predicates. From my admittedly RDF-biased viewpoint, it still seems to me that the distinction between properties and relations is a rather artificial one. However, having not yet studied or implemented a system in Neo4j, I can't criticize what may be a pragmatic design decision. I'll think about this as I read through your Graph Databases book (thanks for making the early release available for free!).

[Michael B.]

I don't see the big deal here. I've worked a bit with OWL ontologies before and switched to Neo4j recently, because the logical structuring into nodes and relationships makes way more sense. Look at it this way:

You have triples with subject-predicate-object. The predicate doesn't belong to either of them, but is more of a connecting piece, which should point to the two entities, instead of being a property of one of them. With SPARQL/RDF you'd probably have this sort of query:

PREFIX ont:  <http://xmlns.com/ont/0.1/>
SELECT *
WHERE {
    ?person foaf:worksfor ?company
}

While in Cypher, you'd have something like

match p:person-[:`works for`]-c:company
return p,c;

Keep in mind - it's not a document oriented database and not an object store either. We're not querying for a property of some object, but for relationships.

If you'd have to check properties, you'll end up iterating over all nodes in your graph and see if they contain some sort of link to other documents. RDF stores usually run on normal relational databases, which would go ahead and create complex indexing strategies to work around this issue. As soon as you change your property model, they'd have to rearrange and reindex all of that.

Working with a graph database, which doesn't treat relationships as properties, you just have to filter the relationships down to a desired type (if necessary) and just iterate over all of them and fetch the node pairs. This makes way more sense architecturally and ought to have better performance, no matter how you see it.

On Saturday, 18 May 2013 04:04:48 UTC+2, Gary Schiltz wrote:

I've just started looking at Neo4j, and don't understand the reason for having both properties and relations - they seem redundant to me. I have quite a bit of experience with RDF, where you basically just have resources with predicates that link together two resources. So, what distinguishes (at a conceptual level) a property from a relation? If these are FAQs, I would appreciate a pointer to some background material that discusses properties vs. relations. Thanks.

[Gary Schiltz]

Thanks Michael, that's helpful, and the kind of discussion I hadn't yet found.

[Michael B.]

Here's another thing:

With RDF/OWL triplet stores, you usually do a great deal of modeling first, then take care of data. One of the main reasons for that is the inflexibility of the data structures behind it. Aside from being a strict XML format, which requires a static schema (all changes are done by versioning...), the underlying stores need to be readjusted for all changes...

NoSQL databases are very different from that. Of course, you still need some use case and data model when you start developing. Still, from my experience these databases evolve quite a bit over time. The whole point of document databases such as MongoDB is not knowing what kind of information you're going to store beforehand. The whole point of graph databases such as Neo4j is not knowing how your entities might relate ;)

With RDF modeling, you need a distinct set of relationships, which your entities will have. It's very similar to relational databases. Imagine a table for each class - you'd have a column for each property and the one with your "relationship" would have a foreign key in it. That's a pretty static data model.

For Graph databases, relationships are not simply properties (foreign keys) of nodes. When implemented properly, they're stored in a generic index (I think B-Trees are most appropriate for that) which allows you to search for them and get the belonging head & tail node (if they're directed at all, you don't always have directed connections). That allows you to add relationships as you see fit without further adjustments.

Especially with knowledge management / text mining, I see a great benefit vs. classic RDF modeling. You don't have to invest large amounts of time in your modeling, but dynamically add labeled data to your graph as you see fit. 

Regards,

Michael