Relationships-categorization system wanted features

Events happening in the community are now at Drupal community events on www.drupal.org.
mki's picture
Posted by mki on December 15, 2006 at 1:49pm

"Relationship" I understood as relationships between fields (nodes are many relationships, which are subject of more advanced process).

Wanted features:

  1. Powerful and without limitation thanks to the most abstract (see: "everything is a field", compare this to: Global CCK fields, A controversial(?) point: store translations as nodes).
  2. Build-in categorization features.
  3. Build-in views features (listing fields, not necessary nodes).
  4. Build-in menu features.
  5. Support for Semantic Web/Microformats/similar.

Observations about current situation:

  1. Drupal still need and looking for relationships system that will be include to the core.
  2. There are several modules that providing this partially and in different way, e.g. Relationship, NINA, Eaton's proposal, Category, Subform, Nodereference, Editview (sorry for didn't list all) and Drupal enhancement proposal: Relationship API.
  3. We need to join current deep-rooted idea, e.g. taxonomy, menu system, with the new (small revolution), solve many problems, e.g. high-performance, create well thought out readmap to this changes.
  4. I dream of searching relationships-categorization system for Drupal 6 core like in case i18n. I hope Gábor, as he said, will move this forward.
Categories: , , , , , , , , , ,

Comments

Sounds like a really

Posted by anthonyoliver on December 19, 2006 at 3:13pm
anthonyoliver's picture

Sounds like a really interesting idea. Although I think it would be a good idea, I think it would increase the learning curve for drupal. I think your right in shooting for v6 because maybe by that time we will have drupal distributions so it won't be so much of an issue.

http://xamox.NET

You forgot clipper.

Posted by Bèr Kessels on December 25, 2006 at 1:02pm
Bèr Kessels's picture

.. which is simple, but works like a charm. The module itself is not a relationship API, but it uses a standardised relationship table. shazamgallery uses the same table, for example.

http://www.webschuur.com | http://bler.webschuur.com

Sorry, yet I wrote this

Posted by mki on December 25, 2006 at 9:08pm
mki's picture

Sorry, yet I wrote this without the intention of listing all diverse projects (so most likely not only clipper wasn't listed), just in order to some common solution to Drupal core.

How is this relationship

Posted by sarvi on December 27, 2006 at 7:44pm
sarvi's picture

How is this relationship module/functionality related to the "relationship" defined in the sub-form module(http://drupal.org/project/subform).
It seems to be talking about establishing relationship between CCK content types. It seems very useful to me.
It would also be useful to establish relationships between actual instances of CCK content types.

Is this the same. If not, should they be?

Sarvi

Subform module can establish

Posted by mki on December 28, 2006 at 3:11pm
mki's picture

Subform module can establish which content type can be relateted to other content type, and on this basis, establish relationship between nodes, that belong to above-mentioned content types. This looks like:

content type 1 }----{ content type 2
       ||                   ||
       \/                   \/ 
     node 1    }----{      node 2

But in this story, I am talking about any kind of relationship:

field  }--{ field
node }--{ field
content type }--{ content type
anything  }--{  anything

Some useful information you can find in SuperClasses, SubClasses and Instances by dman.

relationship is the right module for this to be based on

Posted by drafnor on January 28, 2007 at 9:10am
drafnor's picture

If you want something as broad and powerful as that then surely relationship is the module you want to base it off. Relationships could work with CCK, is RDF ready, can easily accomodate microformats and everything else on that list. My feeling is that the only reason drupalers havent jumped on this is that its probably too far ahead of its time 9as far as drupaklers are concerned). But Im convinced eventually drupallers will only end up building the same functionality via a long tortous, less standards based and more difficult route.

http://drupal.org/project/relationship

Relationships API

Posted by mki on February 1, 2007 at 12:36am
mki's picture

I'd like to refer to [development] relationships API vs i18n discussion on lists.drupal.org.

I was thinking about:

  • one, common API for one, common "relation" super-class, and
  • diffrent tables for every relation type (sub-class),

just like in CCK, where we have node super-class, and content types sub-classes with own tables.

CREATE TABLE relation_*relation_type* (
   object TYPE,
   subject TYPE
)

For example:

CREATE TABLE relation_author (
   uid INT,
   nid INT
)

CREATE TABLE relation_source (
   nid INT,
   url VARCHAR
)
CREATE TABLE relation_translation (
   nid INT,
   nid INT,
   language VARCHAR
)

Object and subject fields can have different database types, so we can establish every type of relationship, for example between node (nid INT) and resource from outside (url VARCHAR). As well, also every relation table can have peculiar fields for storing some additional information, like translation language or something else.

example between node (nid

Posted by neopup on September 26, 2007 at 11:21am
neopup's picture

example between node (nid INT) and resource from outside (url VARCHAR). More plz?

my site:altonia

alltonia

Relationships & site structuring

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week

See all hot content.