What are Plans for relationships in Drupal

By jasonwhat on 26 Jan 2006 at 21:51 UTC

My head is spinning trying to read up on all the relationship modules in Drupal. Their is tagnode, CCK coming, relationships.module, category module, relativity module (which seems to be deprecated) and more. I've found serveral discussions on RDF metadata: http://drupal.org/node/17302, http://www.ent.iastate.edu/misc/jv/metadataroadmap/, http://drupal.org/node/37556, and also know there are interesting things happening with XML and the books module, not to mention flexinode and tags.

I'm working on a new node type that all other nodes on the site will relate to. Each news story, blog post, and aggregated item will relate back to one of the "anchor node types." I've thought through several ways to do this using relativity, tagging, tagnode, but I'm concerned that once I decide on a solution, the handling of relationships will be totally altered. Right now I really need some functions in relativity, and some in tagnode to do what I want, but relationship.module and upcoming CCK seem more flexible. I guess I'm not as much looking for an answer on how to do what I want, but general explanation of what is happening with relationships in terms of drupal core and the many separate modules.

Comments

I can't speak for the others,

dman commented 29 January 2006 at 09:03

... and I've written way to much about my own concepts of how things should go, but I'll merge your question with this issue and try to find where we can crossover.

Foundation on/for CCK?

tomamic - January 28, 2006 - 23:13

But, though I think {relationship.module} has a stronger logical grounding, better support for standards etc., it seems strictly related to the parallel CCK effort. Could the two be merged somehow? Sure, CCK has a different target, changing the way drupal works in its core. Relationships don't replace existing node structures, but add annotations. Right?

Thanks for the reference here to that metadata roadmap. I spells out wonderfully clearly what I've come to realize after implimenting (limited) domain and range support for my interface.

To define a Drupal content-type:

state what properties it is allowed to have. (title,author,ispublished)
state what values that predicate can have. (literal,user,boolean)

... and the editing GUI, and indeed the view can be made up from that!

Drupal (currently) falls just short of that concept, which the doc refers to as MFR MetadataFRamework.
Custom nodes all patch on their own fields in their own ways. Flexinode does some things right, but seems a little shortsighted and harder to extend upon.

I came around to this way of thinking when I realised that instead of creating a new data type for my 'predicate' definitions, I was better off creating what I call a data cloud. A collection of small statements about one resource that together told me what I needed to know, but individually were managable under a totally different framework.

I'm starting to consider how I can access core Drupal node properties via my interface (functionality is there in the module, but turned off). As described (again in that roadmap document) the 'title' of a node is simply one of its properties, and I believe it could be administered using my predicates interface, but I stopped experimenting with that because it was confusing :-B

If the CCK thing comes to the fore, and it does indeed hold true to the views in the roadmap, then we'll have a lot in common. Maybe I'll help on the standards-compliance, metadata-query, OWL Ontology, Inference rules side of things. Less on redesigning the 'node type'. I like the idea of the widget things, I was sort of getting there myself without seeing that was what I was building.
The difference between my approach and those I've seen in parallal is just my attempt to leverage existing (W3C et al) Knowlege System work and express it using established terminology and structure. Others who are closer to Drupal are inclined to start with the existing guts and evolve it into something. My attack is layering info on the top.

I always write too much

... as anyone who's seen my code comments will attest. BUT to respond to your Original question, and the one I reposted here,
A lot of people are keen on the idea of a relationships API - so whatever engine is at work behind the scenes can be reworked without you having to make design changes.
This is, in the first instance, a code-level issue, so I'm not sure how that helps your decision, save that I see it as trivial to IMPORT most existing relationship-type data into the schema I envisage.

.dan.

http://www.coders.co.nz/

_{.dan. is the New Zealand Drupal Developer working on Government Web Standards}

Here is a link to the

tomamic commented 29 January 2006 at 12:44

Here is a link to the current cck implementation (at least, I guess it is). Just in case someone hasn't noticed it - it is not very visible.

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/cck/

My own two cents about cck and your module: I think structuring the module on top of cck (in the long term), adding rdf compliance and inferencing, would take the best of both. I guess you're right: it's mostly implementation - and one could easily transform annotations from one representation to the other. Yet, both developers and users would benefit from a unified model.

Anyway, I think it's a great first step!

I'm interested in semantic web and e-learning, and I'm evaluating different CMSs. I think Drupal has a great potential in those fields.

Probably, if you could draft an api for plugging different inference engines in your module, it could also take benefit from more contributions. A lot of work has already been done, though most of it is written in Java, and it hasn't reached widespread applications, yet.

http://www.w3.org/2004/OWL/#reasoners

Will Drupal be the killer application for semweb? :)

A lot of people are working on semantic-web-services, integration and translation between different ontologies... That's important, but taking it all back to document annotation - where it started from - could give it some fresh air! :)

Again - great work!