Will AR eventually support relationships with values? Some relationships have values associated with them, that are different for each instance of the relationship type. For example:
BigCorp--(Donated [$500k] to)->PolticalParty
The (Donated [$ ?] to) relationship is re-usable, where as a (Donated $500k to) relationship would not be. Obviously a simplified (Donated to) relationship will always be appropriate, but it provides far less information.
Also, some relationship types can have multiple values, for example, minimum and maximum values, or any other number of (not-necessarily numerical) values.
I ask this mostly because I'm working on http://drupal.org/project/graphviz_noderef , and am wondering if AR will eventually provide a good basis for this (especially since it's possible that this module will replace the node and user-ref field in cck, right?)
Comments
Comment #1
jpstrikesback commentedThis is probably where relationships as entities shines me thinks, Donated to = relationship entity bundle, Amount is a Field attached to the bundle...am I thinking right here? Although that depends on the directional nature...if there is one...perhaps that could be defined in a field??
Comment #2
dman commentedNo, a relationship is a line in a graph, it has two ends and a label. It's a 'statement' or a 'triple'
If you find you had to model a bigger concept (eg donation) then you make an entity for it and add statements to it.
donation->madeby:[me]
donation->madeto:[charity]
donation->amount:$500
donation->date:2010-10-10
donation->attached_note:"Thanks a lot!"
... a node, with relationships attached to it
Comment #3
chx commentedFielding relationships is very possible already just there is no UI.
Comment #4
damien tournoud commentedIsn't there some underlying code to fix here, as well as pulling the switch from 'fieldable' => FALSE to 'fieldable' => TRUE?
Comment #5
naught101 commented@dman: sure. But awesomerelationships are entities already. No need to make them nodes.
Actually, the entities are awesomerelationship instances, aren't they? So it makes perfect sense to make an awesomerelationship with a bunch of sub-relationships.
Comment #6
sunComment #7
naught101 commentedhttp://www.w3.org/TR/swbp-n-aryRelations/
Comment #8
dman commented@naught
Indeed, the formulation described in that doc is what I was describing in #2
When you need n-ary relationships, you introduce a new placeholder event or data object that can hold many properties and group them together. You don't overload the relation itself (the graph line) - you give it a new, richer target.
If our concept here of a 'relation' is already a fieldable entity (node or not) then it's already overloaded ... and so yes it can be extended into filling this role. But that makes it no longer a relationship line in the graph, it makes it a full [graph theory "node" not necessarily Drupal "node"]. And it means that a "relation" entity type needs to be subclassed to fill different uses.
Knowing when to break out into this more complex model is tricky. Even making the distinction can be hard to explain in trivial cases. But they are two approaches, and it helps to be clear to know which is which.
In Drupal-think, I'd prefer to expose the new joiner data object as a Drupal node that uses relations rather than as a special type of relation. But both approaches are probably compatible, depending on needs.
That is sort of the difference between the http://www.w3.org/TR/swbp-n-aryRelations/ first example, using null (unnamed) joiner objects and using instantiated (named) objects for the job. I prefer the second approach for complex stuff. It makes things more readable (to me).
Comment #9
sun@dman: Most of that is going to be a field. Copying from #981398: Bundle creation and UI:
Comment #10
naught101 commentedWhat is this, battle of the flowcharts?
dman: Now that we have entities, I don't think there's much reason to make n-ary relationships into nodes. After all, a node is just an entity with a bunch of crap that we don't need (eg. comment, sticky, promote settings, author, datestamp, etc. etc.). With node EntityFieldQuery and the upcoming EFQ views backend it'll be pretty easy to create a decent searchable listing of relationships or entities with relationships. I can't see much need for actually having a page dedicated to a relationship in most cases, but for the edge cases it wouldn't be hard to have a relation/ page just using hook_menu and a custom page callback.
Re: that graph you posted: since any relation must have, at minimum, a subject and a predicate (with or without an object), you can just choose a standard "owner" for this relationship type, with an appropriate verb (eg. John:buys, books.example.com:sells, or even Lenny_the_Lion:is bought by), and attach the relationship entity to the "owner" entity as a field, which is the aim here.
I definitely think though, that there will still be a use for a very basic relationship module without any of this overhead. references.module (successor to node_reference etc.) perhaps, although the main reason this module was conceived was that the *_reference modules weren't unidirectional, and backlink modules are a pain in the arse. Maybe an empty entity won't have enough overhead to bother having a separate module though?
Comment #11
dman commentedYeah, I'm not worried about the difference between a 'node' and an 'entity'. I'm not pushing for that. Typed, manageable entities are fine.
I do however want to distinguish between a subject-predicate-object relationship as a small, limited building block, and bigger versions of that such as the extended 'donation' or 'purchase' data object that is an aggregate of simple relations.
Expanding the minimal relation concept into a 'relation entity object' that can have any number of fields, attributes and other relations leaves us with the same question on how to deal with the 'relations' it contains. Are each of them relation entity objects also? Is it elephants all the way down?
I say the 'relationship' triple is the base building block. Anything more complex is a bigger thing, and probably deserves to be modeled as such. XML schema calls it a "ComplexType" because it is. That W3C document explicitly recommends you do that.
n-ary statements are complex types. Model them as entities or whatever. It actually helps your data architecture to identify these decisions. It helps write queries later.
But what then is a simple type? That is the core, RDF-style A-hasproperty-B relationship.
Overloading that relationship (which can of course be done, especially once you bring provenance, history or trust into it) just opens an infinite regress ... unless you are very careful.
So I'm suggesting we be careful - do not overload the core concept of 'relation' with n-ary functions. - move as quickly as possible to heavier-duty entities for complex types, but don't muddy up the building blocks.
... I say this from experience because I tried the pure "everything can be described in terms of everything else, even the relationships that describe how things are related" approach and got overly abstracted and crashed with my earlier "relationship.module"
Comment #12
naught101 commentedHrm. SO, I don't think we've got the fieldable relations thing properly sorted yet. And I think this issue is where it's most important. Here are some thoughts:
relation, each auxillary relation attached to that)
attached to one source (the one with the field group)
settings, rip from content_type/manage fields
sub-fields back in to the widget
- give options: e.g select subject, object, and auxillary phrases,
predicates
for each direction, the preposition for each of the adpositional
phrases)
- we can't control options? (1) somehow have to add settings as fields
field and subfield tokens? this would allow people to make proper
sentences out of the fields: "[subject] [predicate] [object],
[preposition] [auxillary object]" where preposition is the "predicate"
for the auxillary relation.
I think I'm probably forgetting some problems that having fieldable relations causes...
Comment #13
ronald_istos commentedHi - if you want to follow lessons learned from RDF-style semantics then dman's approach is largely right. You don't type lines in a graph. I realize that technically its possible but it can easily grow into a nightmare to handle and moves you away from being able to easily plug in to years of RDF work.
So rather than:
BigCorp--(Donated [$500k] to)->PolticalParty
You have
BigCorp-madeDonation->Donation1
Donation1--madeOutTo-->BigCorp
Donation1--hasAmount-->$500k
In RDF these are called auxiliary or blank nodes (not Drupal nodes!) and are there precisely for this reason. Getting slightly pedantic - referring to #12 the relationship is real it is the node that is auxiliary :-)
Anyway - it looks like naught101 is agreeing but not quite sure.
In terms of the UI you would want to be able to create a new entity bundle instance (i.e. Donation) and then fill out the information there (i.e. subfields back in the widget). Was trying to parse the table above and looks to me like like this is what you are saying?
Comment #14
dman commentedFor those interested in this line of thought, I heartily recommend clicking around in freebase http://freebase.com/
There we see how, instead of making a (straightforward-seeming) statement like 'Obama is President of the United States"
it gets broken down into
"Barack Obama is a person" http://www.freebase.com/view/en/barack_obama
"Barack Obama is a politician" /government/politician
"Barack Obama has a political appointment (government position held)" http://www.freebase.com/view/m/04s_2dh
"The position is 'President of the United States'" http://www.freebase.com/view/en/president_of_the_united_states
... which has a duration, and other sundry attributes.
Instead of overloading the relationship, the data model expands to treat "political appointment" as a rich data point of its own.
What looked like an "A is B" statement becomes several statements "A and B participate in datapoint C"
It can lead to an unlimited regress, but you need at least ONE regress if you find that a graph line (triple) relationship needs even one extra property
Comment #15
Shadlington commentedTagging
Comment #16
rlmumfordI think I'm with d-man. A relationship should be a triple.
Comment #17
naught101 commentedThis is fixed in #1113654: Relation reboot.
I'm sure it'll horrify dman and rlmumford, but relations can now be n-ary "octopus" relations (ie. Rob, Mary, Ben are siblings), OR relations-on-relations. We leave it up the the end user to completely destroy their mind with the contemplation of the complexities involved here.
At the moment, we're working on the assumption that "octopus" style relations with arity>2 cannot be directional. If anyone thinks this is a bad assumption, and can come up with a decent use case that explains why, please feel free to re-open this issue, and keep the discussion over here.