Do you have a 4.7 version of this module yet? I am porting several sites over to Drupal and looking at various ways to link data together and this looks very powerful, but I'm working in 4.7 so I don't have to reinvent the wheel later.

Comments

dman’s picture

dman commented
Assigned: Unassigned » dman

I'm creeping toward it.
Trying to abstract the base API from the configurational settings and forms as much as possible before I do so. My baseline is a 4.6 (paying) client, so the 4.7 implimentation will be just a layer for a while. Hoping to seperate form from function to keep the core compatable.
I did a few commits earlier this week towards this end, and I appreciate that it's now a bit more important than it was at the turn of the year when I made my first burst of commits.

Things I've been learning recently mean that when a 4.7 is available it'll be trying pretty hard to import settings established with your flexinode or CCK node types - there'll be an 'import' option or at least pretty clear conversion path from established methodologies.

BUT it's all still proof-of-concept code so far, and will need some work to make it efficient or scalable over large data sets.

The most help anyone can be right now is describing your use-case scenarios. Please tell me how you want to use it and what inerface you'd like to see to manage it, and it'll inspire me to make it so.

Where do you see this going ... in the real world?

.dan.

tema’s picture

tema commented

dman: "Where do you see this going ... in the real world?"

I think it's really important. Now we see the main conseption: CCK is for data structuring, storing and retrieving, Views is for custom displaying, sorting, queuing etc. Now what? We need a custom data linking module! There is a Node Reference field in CCK and it's useful for now, but we need some more flexible and... standard. Dman! Your module is candidate #1 for me!

dman’s picture

dman commented

I appreciate the enthusiasm, (and apologise to anyone tracking that there's been nothing to show for a few weeks) but my question about the real world is :

What actual data types do you actually want to link to other resources?
Plenty of people have talked vaguely about how versatile and far-reaching this could be (myself included, of course) but to build and test and prioritise which bits to get working first, I'm trying to imagine specific implimentations.

My prime mover was (as linked when I first came up with the idea) structuring government legislations and stuff with their versioning, dependancies, and authoratative chains.

Some folk have expressed interest in it taking the place of taxonomy but I don't want that - if data can be grouped or structured using flat or nested vocabularies, that's what you should be using. This is primarily for ad-hoc links, see-also links and things.

It's well-suited to describe all the characters in a novel or a play (I remember a great mythology site that listed the Greek pantheon with links to 'father, mother, child, protagonist, legend, place' that any other character, event or place referred to.

So, what is your dataset? What, specifically, is the current or planned content of the site you'd see this going in?
I want to work on getting this going again, but I need a few targets to aim at.

.dan.

tema’s picture

tema commented

So my real world example is a description of tarification system (see wikipedia) or any service/payment structure with filtering, sorting, pre-calculations, "what-if" etc.

I want to have ability to build myown ontology for my real-world task (and maybe to share it after all).

I think there must be a public repository to store any custom ontologies. Most beautiful ones can be rised to the standard by some wise guys who keep it :)

karens’s picture

karens commented

I have several sites and was thinking about using it differently on them:

One site is a fishing tournment site. I want to create events as nodes, teams as nodes (they fish in teams), the tournment itself as a node, and the fishermen as nodes, then connect teams to events, fishermen to teams, fishermen to the tournament main page, etc. I could use taxonomy, but there will be so many links that I need something that produces lists of links with some sort of explanation of how everything is related rather than a couple of links at the top of the node that I would get with taxonomy.

Another site is a sourcebook on eldercare issues where I have stories, events, sponsors, yellowpage listings, a glossary, and taxonomy groupings (actually I will probably end up using category instead of taxonomy). I want to be able to link various elements together in numerous ways -- a yellow pages listing needs to be linked to the topic it relates to, sponsors need to be linked to the right type of content, stories, sponsors, and topics need to be linked to events, etc. Again, some of this will be done using taxonomy or category, but where something has a long list of linked elements I will need a themeable (and maybe a paged) list to display on the parent element with better descriptions of how everything relates.

One of the problems will be to control links based on the access of the node that is being linked to. For instance, my "fishermen" nodes have people's names and I may not want them to be publically displayed, so I need the link to maintain the same access control that I give to the node. In other words, I don't want the link displayed to anyone who is not supposed to be able to view that person's record.

An interesting idea for items that have a lot of relationships would be to show the relationship links on a separate "Relationships" or "Related Items" tab -- I have been playing with that idea and it seems doable. Again, this is something that can't be done with taxonomy.

I have been looking at other modules like clipper and relativity. Clipper only allows hierarchical (parent/child) relationships, which is too limiting. I found Tag Node to be confusing to use for some reason, might just be that I didn't spend enough time with it. Node Relativity comes pretty close to what I really want, but doesn't seem to be slated for future development, at least there is no one right now who seems to want primary responsibility for maintaining it into the future.

dman’s picture

dman commented

[Copied from an email asking about progress]

The main holdup has been real-world clients paying me real-world dollars to do (boring) Drupal stuff and that's been taking a bit of my drive away from it.

Secondly, I have spent most of the days when I did attack 4.7 conversion fighting with the forms API and how to get my old nifty widgets through the new system.

Anyway, I've decided to tag and commit the work-in-progress that I've done so far tonight, but it's all in bits at the moment.

Most importantly, the caching of the datastore requests has been taken off, so it'll be a resource hog in some places - I used to retrieve all statements about a resource in one go, but in trying to strip the datastore down to a basic API I now have to make lots of little lookups.

I've been trying (too much) to be clever with OWL logic and defining domains and ranges to say what relationship term (predicate) can be applied to what resource (node type) and what the legal values for this relationship (object) are.
I know what I want to achieve, but I've been coding it a bit piecemeal so far.

Now I've finally (I think) broken through most of the forms API learning curve, I may be able to revisit some of the core issues that have been getting a bit crufty during development as I had to create work-arounds.

SO there is a new 4.7 CVS available, but I can't vouch for it's usability yet.

I'm actually going on vacation next week, so not much useful will be happening until the middle of next month. I have no objection to anyone trying to piece together bits they find in my code there, and I can answer any questions, as long as you had a look at the extensive docs embedded in there first.

Sorry thid hasn't been charging ahead, but I guess I really need to get funded in order to prioritize it.

.dan.

dman’s picture

dman commented
Status: Active » Closed (fixed)

Long fixed or dead. Time to clean up the queue.