Posted by dman on December 11, 2005 at 9:59pm
If anyone wants a look.
You'll find it over here
... following on from last months discussions I still seem to have no CVS account so I gotta go it alone.
Sorry if some folk will find what it does rather theoretical, I've built it up from first principles - each term is defined in using other simple terms, eventually creating a complex system.
... this is not what most users want to see, there's a UI layer to go on the top, really!
.dan.
Comments
Looks great
It would be good if the authors of the several other relationship modules out there, tagnode, node relationships, clipper, etc. would explain the status of their modules in this thread.
I haven't played with the new category module yet, but does this replicate some of that functionality? My head is getting dizzy trying to see how relationships should and do relate to Taxonomy. Should relationships be separate, or part of taxonomy?
Well, without wanting to fix
Well, without wanting to fix something that ain't broken, conceptually I see taxomomy as a subset of the functionality of true relativity.
Currently nodes that participate in a taxonomy simply have an 'isMember' relationship with that term. Taxonomy heirachy is layered into that.
At one point I looked at using taxonomy to manage my predicate keywords ... but seeing as I wanted to add extra properties to them (transitive or inverse relations, cardinality characteristics) And I already had a term database being built, there wasn't much left for taxonomy to offer - other than existing familiarity.
So my term edit screen is modelled heavily on taxonomy.module.
... but under the hood I gutted it. All my 'terms' are actually data clouds of related statements. Inefficient in some ways, unbelievably flexible in others.
I've put a lot of work into the predicate terms, but what I started with, and what I hope to finish with is a simple interface for adding 'related links' that are cannonically categorized.
I admit I need to do some more looking into what other folk have done :-B . I've been in my own little world for a week or two,
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Tags?
I see what you are saying. However, I think tagging is changing relationship functionality somewhat. For example, I know of modules in the works that can display all nodes tagged with a word inline to the currently viewed node. I wonder if it makes sense to look into tagedelic and see how nodes might relate automatically based on tags. I'm not sure if any of this would fit into what you are doing, or if it is all separate, but it each case we are talking about how nodes relate. Perhaps a very general api should take things like tagging into account.
Taxonomy doesn't allow for
Taxonomy doesn't allow for relationships like dman's module is building. This essentially makes drupal capable of handling semantic web type website which is something that will make Drupal rediculously powerful for future apps that need to create semantic relationships between nodes... Can't wait for it to be completed considering the fact that this would make it perfect to build your own personal knowledge base of things that you've studied or work on. At least that's my take on it, correct as necessary! I really wonder though how navigation for the relationships will work, going to go explore the website to look into it further!
--
Please read the handbook, search the forums, then ask...
http://drupal.etopian.net (Drupal Support) | http://www.drupalshowcase.com
Semantic navigation
So far I've got configurable blocks, that can pull out any or all of the relationships.
Currently turned on is the 'everything' block - for analysis.
That's well-suited to the 'references', bibliography or related links requirements.
There's also a makeshift page-turner block and footer nav in my emulation of the book module
All that structure is from (as few as possible) relationships,
I've also got a nodeapi hook called in my 'revision control' ontology set to alert you to a newer version of a 'replaced' page.
Basically any sort of navigation, many existing modules can be emulated with this theory.
I even have a prototype discussion thread ontology - well fun.
As for sematic web - that's what it's all about. Each relationship defined (or deduced) for a page is also being inserted into the header as LINK REL , and there is that metadata standalone RDF resource at the foot of the page too. (Need work to link back to the full URLs I think)
AND, thanks to other folk publishing their stuff in nice RDF, I can absorb ifo from elsewhere, I've got a few shortcut links at the bottom of this page - which I use to absorb new terms - but the URL import also works on anyone elses RDF/RSS feed or metadata...
It's amazing what started falling together after I finally grokked namespaces :-B
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
tagnode's future
Thanks dman for your very capable efforts.
Jason asked the status of all the relations modules out there. I can speak for my simple, "me too" relations module, tagnode. I am 60% finished converting this module to 4.7. I have been following the activities of Vlado (e.g. see here http://dikini.net/tags/relations ). I believe a number of us interested in this problem were looking to him to get the ball rolling. However, it looks like dman is certainly onto something as well.
I expect that once a model is agreed upon for a generalized relations API/module, I would probably merge my dev efforts with that API/module. However until there is a production-ready relations module that has all of the (basic) functionality in tagnode, I will continue to support tagnode for 4.6 & 4.7
dado
http://schtickdisc.org
dado
http://schtickdisc.org
my code status and misc notes
I rewrote the sqlgeneration, since my last update. Over the last weekend I adopted a little bit different approach to tackling the generation of queries, so it uses php to be "the language" for relation definitions. I added support for joins, limits, and a few others. unfortunately bryght svn is down, otherwise I would have updated that. I've spent some time implementing unit tests for this, so I can be sure I'm not going mad with the results.
What next? Tonight I will add a minor aliasing update and the SQL (selection) part is majorly finished, bar the support for stored relations, which uis next on the agenda.
Then comes theming - which is an interesting problem on it's own right.
Along the way I'm going to be dragging a few example use cases. I think Dan's ontology ideas are a definite candidate. As well as node remixing and custom (node) similarity metrics.
Dan is doing a great job by the way. I have only one problem with his approach - it is bound to be very heavy, otherwise it is quite comprehensive.
Still a way to go...
Mmm, Aliasing made my code a lot messier than I wanted it. It got very annoying very quick.
And I'm sure finding my piecemeal queries heavy! It's a side-effect of reading to much and having the eureka moment that told me that EVERYTHING could be expressed in triples. But just because it can doesn't mean it should ;-)
This became a lot worse when I refactored all my predicate terms to be defined in terms of other, smaller statements.
Pretty soon I'll cache them again - I don't expect more than 2 or three dozen to be actually in use, but for now I'm just treating them as other target 'subjects' .
I've avoided putting too much thought into the DB calls as much as possible - I was hoping to be able to plug into whatever triplestore query engine you come up with - if we can ever meet in the middle somewhere. I know we are approaching this beast from totally different ends :-)
ALSO ... a really heavy area (neccessarily) is my inference engine, which, although it caches during a request, does so each and every time. I'm thinking of creating a shadow cache to hold just the implicit or deduced 'facts' separate from the explicit ones. (Or just tag them as such in the table).
What I mean is that given two statements:
I can easily deduce
(Note that I'm here defining 'hasPart' to be transitive, and 'contains' to be direct - it's a terminology thing). And although some folk think the inverse relationships should be built-in, I treat them as two unique, complimentary facts.
These secondary facts would be quicker to just remember, BUT I didn't want to populate the DB with thousands of details I didn't really care to administer. ... so they are calculated each time.
Anyway. I'm approaching the UI again now. Now I have ontolgy group support, I'll start enforcing domains and ranges - which terms can apply to which types of content
(eg most nodes can haveAuthor, but when you select hasAuthor - the select box (or something) will only present a list of 'users' not nodes.
This will be some javascript magic. (I still can't call it 'Ajax') it's just fecking scripting!
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Well, my personal eureka
Well, my personal eureka moment was that the db is the inference engine. Basically SQL and Prolog meet do have a huge similarity, when you know what are you asking. Unfortunately we have limitations. If our rules are in some form of a tree or a chain, then yes - one simple select with joins would do the job, assuming we are using some implementation like nested sets or similar. Otherwise stored procedures are nessesary. (there goes mysql 4.x.x out of the window)
But Looking at a lot of the use cases, most of the stuff we want is immediately related one way or another, or can be expressed in some fixed fashion, so the above limitation shouldn't be a showstopper of a problem.
I'll try and implement some of the cases you are doing in the db backend, so we can see where all of this meets up.