First of all, I have to admit I haven't installed the module yet, as I'm playing around with 4.7. Also, I'm quite new to Drupal. But I read the long discussions and your documentation, and I also tried the sandbox node on your site. It is definately a GREAT module!

But, though I think it 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?

If I understood correctly, I see strong points in both, differences, but also some overlapping.

One strong point in CCK: it is going to support different datatypes (meaning different editing widgets and different tables in the db), which is a feature I like. Assigning a range to the object of each predicate, and making sense of it in the db and ui, seems to me the way to go.

Thank you for the great work! Which is the best way others could contibute, in your opinion?

Comments

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Just a note about relationships and predicates, in case no one has noticed: there has been for years a standard about this, which is OCL: implementing (part of ?) it would certainly be better than reinventing it, wouldn't it ?

Specification is available from the OMG:
http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

dman’s picture

dman commented

Hey!
I've referred to this query over in the discussion forums.
Come join in there.

As for contributions, Welll...

Actually, what I want is a few real-world use-case scenarios.
What do you WANT this to be able to do for you.
Then I can figure ways of tuning the interface and creating a path to impliment it.

As posted in my first-ever essay on the world of relationships, the client wanted

  • Some pages and sections would have different 'Contact Details' defined in either a heirachical or ad-hoc basis

    • ...

  • And then it got even more fun, Legal Revision Documents, so we needed to be able to define that a doc was 'superceded-by' another one, or was under review and may be replaced by a proposed successor. Think of how the W3C standards are organised, then add a ton of govt-compliance mumbo-jumbo.

Looking at this spec made me explore what was needed to solve the questions in the general case.
The first one, for example, I didn't want to address by just tagging each page with a 'contactee' - I figured there should be some way of calculating what the appropriate contactee was from some higher principle.
If this page does not have an explicit contactee, use the one from the governing body for the current section. ... current section? What does that mean in Drupal-think?

And thus this mess was born.

So. Please start by explaining the domain of your problem. What is the subject matter, and why do you need relationships that can't fit into a heirachical taxonomy tree or three?

I really want to keep this grassrots, as all the (wonderful) semweb demo technologies I've seen never seem to have anything but toy data and FOAF shite in them.

For code, well, obviously post installation issues up here.
Soon I'll be suggesting implimentations of your own ontologies - an ontology of your own can be as simple as a node type of your own - with the data storage taken care of!

dman’s picture

dman commented

F**K - this is why I should keep my long posts to myself, or at least in the forums.
... or, of course, preview :/

dman’s picture

dman commented

Having had a look at the UML link, Um,

It does indeed represent much of the same sort of stuff, but it's

a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems.

- it reads to me like rules for flowcharting. Relevant, but not the same as RDF, which specifies a language for machine-readable relationship statements and interchange.
Both UML and RDF represent the same sort of information, but RDF (and family) represent it in a way that computers can use, and draw inferences from.

I do like what it does for graphing however (I always hated the elipses and arcs they use to illustrate RDF) and just today saw it elegantly used in the metadata roadmap article.

So.. I will keep it in mind next time I need to draw a diagram.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

The OCL part of UML is strictly non-graphical: it's a data description language, allowing for very sophisticated constraints over data: relationships cardinality, computed predicates, and the like.