This might be complete insanity. Bear with me a moment.
I and others have already hinted at trying to create arbitrary RDF relationships with drupal and CCK (For example http://drupal.org/node/704712 and http://drupal.org/project/attribute). Obviously useful in cases where you're mapping data in which you don't know what all the relationships look like (or just can't be arsed mapping them all yourself >:) ). This aspect it more or less underway.
Next comes n-ary relationships. There are some really good example of this in the w3c working group note here: http://www.w3.org/TR/swbp-n-aryRelations/ . One that I'm interested in is the data that's displayed here: http://www.democracy4sale.org/index.php?option=com_chronocontact&Itemid=30
The data is basically :
[Organisation A] [donated] $[XXX] on [Date] to [Political party B]
Which in n-ary RDF style might be represented as:
Org A > madeDonation > Donation4324
Donation4324 > hasRecipient > Party B
Donation4324 > hasDate > Date
Donation4324 > hasValue > XXX
A form for this might look like:
(where this is a CCK field/multigroup/whatever on the OganisaitonA node)
It's then just a matter of creating some code to handle this data in an appropriate way. (Something nice might be a graph, with organisations/parties as nodes, and donations styled according to date and value). Of course, this particular data is probably more appropriate to a table, rather than RDF, but I'm sure there are other examples that are suitable. (And I'm not sure how this data would be stored or output)
Then, once you've got that sorted, you start to hit the same wall as you did with unary relationships: how do you deal with data that you don't know the format for? So I got to thinking, I wonder if you could make a completely arbitrary n-ary relationship data input? Something like this:
Where the "target" is a standardised "main" relationship (ie. the object of the original sentence ("Organisation A donated to Political Party B"), and it's possible to add more "additional data" relationships as needed (yeah, these names aren't great).
-----
Ok.. I've got part of that out of my head now. Discussion would be most useful for me, as I'm still completely unsure of the usefulness of RDF as a method of dealing with this kind of information. So: insanity or no?
| Attachment | Size |
|---|---|
| arbitrary relationship.png | 9.93 KB |
| arbitrary n-ary relationship.png | 13.34 KB |
Comments
On the same page with you - not insanity at all
I have been thinking along the same lines for some time now. I am not a developer though, so I have had little chance of seeing my theories through to reality. The little bit of background for where I am coming from and how far I have gotten with Drupal/RDF etc. is outlined in my post on the OpenPublish Group
Integrating Open Publish 1.7.1 articles with CiviCRM contacts
Although I cannot determine technically if CiviCRM is using RDF triplets for its relationship mapping, my sense so far is that it is not and I can't see anything that leads me to believe it will or really needs to for its own purposes. I just liked the fact that something hooked into Drupal had the ability to create RDF triplet style relationships.
Since my posting on the OpenPublish Group and knowing that there is lacking integration between Drupal and CiviCRM, I have been playing with D6 and D7 at creating various node types with CCK and trying to create RDF triplet relationships between the nodes. This would definitely build stronger capabilities being tightly aligned with the Drupal core capability, especially in D7. However, no real luck so far.
My end game is ultimately to build a visual interface to the semantic network that is built on using Drupal RDF capabilities. You mention handling the data in a nice way, such as mapping etc. This is the only way I can see the information being truly interpretive to the user. As an example of what I would like to do, have a look at a sample insight map on my website. It is a Flash file, so you will need to open it in a browser to get it to work. Some browsers don't recognize the file type.
I would love to chat with you about all of this offline if you are up for it.
Cheers
In your particular example, I
In your particular example, I believe you could do it without any fancy n-ary relationship shenanigans.
You would just need to create a Donation content type. This content type would have the fields for Recipient, hasDate, and hasValue. You would then have an Organization content type that would have a node reference field with the madeDonation property mapped to it. You would then point the noderef fields on Organization instances to the appropriate instance(s) of Donation.
The arbitrariness... that is a little trickier.
Yeah, I know it's possible to
Yeah, I know it's possible to do it that way, but that's just an example. What if you have 20 different possible input data types that are similar to, but not the same as, Donation? Then you need 20 different content types. Abitrary input would enable infinite possible input data types..
Also, logically, the "Donation" resource is sort of a blind node - it's only really relevant as a way of drawing all the relationships into one n-ary relationship, so I don't know if it's meaningful to always make node types for this kind of data.
In a case where you have
In a case where you have column names like Additional data 1 and Additional data 2, I'm not sure that CCK fields are the correct solution. Fields are like columns in a database—the column represents an attribute and the values in the column should be the value of the attribute. In your example, you are using numbers, but Additional data would have to be a text field, rather than a numeric field, since it is amorphous. This would mean you couldn't process the data in a meaningful way. The power of a relational database columns (IMO) is in the fact that the structure expresses defined relationships.
However, there might be other use cases where this makes sense. For instance, the field itself could represent something that is logically a superproperty of multiple subproperties. For instance, if the node reference field was parent and you could use the RDF property mother or father in your annotation. At that point, it would make sense to have, since all values are valid parents, but you can offer more description in RDF.
And if I am thinking correctly, in Drupal 7 it shouldn't be too hard to implement it in a module using preprocess to append the value to the appropriate attributes array. You would need to check whether the appropriate attribute type is property or rel. The only thing is, it wouldn't account for reverse relationships (the rev tag in HTML).
Unfortunately, this technique would only be sure to work when displaying RDFa on the node, I'm not sure it would work with something like getting the relationships into an ARC2 SPARQL Endpoint.
For anyone stumbling across
For anyone stumbling across this old thread, checkout threw relation module, at drupal.org/project/relation , which does basically what linclark was suggesting, but with custom relation entities, instead of nodes.