| RE: [higgins-dev] Higgins data model |
|
Tom wrote:
Let me see if I understand what you're proposing here with an example:
There is a Tom facet and an Evan facet. Tom has several relationships to Evan. Would these be represented in a single link object with multiple properties?
I was thinking quite the opposite. For each relationship that Tom has with Evan there would be a separate link object.
Perhaps
Link 1: from - Tom to - Evan parentOf legalGuardian soccerCoach
from - Evan to - Tom son
So, rather than Tom having attributes which point to Evan or vice versa, the attributes (properties, sorry) of the link object hold the "pointers" and they are indexed for each of the specified relationships?
I was thinking that the object Tom has a set of relationships. In this case a set of three. So: Tom: hasRelationship - “Link 1a” hasRelationship - “Link 1b” hasRelationship - “Link 1c”
And the relationship link objects would be: Link1a: from – Tom to – Evan type - parentOf
Link1b: from – Tom to – Evan type - legalGuardian
Link1c: from – Tom to – Evan type - soccerCoach
Link2: from – Evan to – Tom type – son
Notice that I snuck in the notion that links have a “type” property. And I think this should be a URI (just like an attribute).
Or would of the specified relationships be represented by another link object? I see how this could be cleaner for indexing and deletion of a link but I also see some potential for additional complexity and potential incongruency with other data models such as a directory.
I'm not sure if it's kosher to consider this when we're discussion a conceptual model but I think it'd be helpful to work out a concrete example and then map it through to a directory data model as well as other data models we know we'll be dealing with.
Thanks, Tom
On your question about attributes vs. relationships in the M4 goals. What's driving things is a desire to consider the link between two objects to itself be an object (with properties). If these link properties are grouped together and "attached to" the link itself management of links is easier. Imagine object A has a link to object B, and A also has a link to object C. And imagine that both links had a common property, "parentOf". Using the proposed approach we simply attach the parentOf property to each link object. If we wish to delete a link, we delete the link and all of its associated properties at the same time. If, on the other hand, we flatten the properties onto A, then we'd need to somehow index the two parentOf properties (of A) in order to distinguish them. To me using the link object as the indexing mechanism is cleaner.
Jim wrote:
The short answer to the question "how would JNDI represent the notion of IdFacet Relationships" would (I think) be to make them attributes.
Like IdFacets, a JNDI object has attributes. A class of attributes would be used as relationship attributes. The syntax of a relationship attribute would be described to have a field for the target facet (may be defined to have other fields as well). Specific instances of these attributes on a facet could be named differently (i.e. role, parent, affinity, etc.).
This begs another question:
In the M4 goals, IdFacetRelationships seem to be seen as separate from Attributes. Why is this? I mean, why not just have attributes which are themselves relationships?
Jim
Task H6-03-24 of the Milestone 0.4 plan (http://spwiki.editme.com/PlanM4) is about "refining the Higgins data model". To support that work we've begun creating listing our goals (http://spwiki.editme.com/DataModelGoalsM4 (this can be linked to from the main Higgins wiki page http://spwiki.editme.com/Higgins).
Let me kick this off with a question:
It has been suggested that instead of creating our own model, we might take a look at using all or some of JNDI. Could someone explain how one best use JNDI to support our notion of "IdFacet Relationships" (see "IdFacet Relationships" (currently item 9,10,11) here: http://spwiki.editme.com/DataModelGoalsM4)?
|