| RE: [higgins-dev] Higgins data model |
|
Hi Jim,
Jim wrote:
Ok, I think I need to run through some example use cases for the light to come on. You're talking about the management of links and the use case is deletion of a link (not of either object). Let's say Case 1 is where we have links as objects (called IdFacetRelationship) which are aggregate parts of an IdFacet. Case 2 is where IdFacet has Attribute objects where an Attribute may be used to link to other IdFacets.
Using the example below (Objects A, B, and C), let's delete the link between A and C:
In Case 1, A has some IdFacetRelationship objects, two of which have a property called "parentOf" (there may be other types of relationships to A and C and others). <aside>We haven't talked about what the value of "parentOf" is yet. Does the value name the object to which A is a parent of? Or is the property name actually "type" with a value of "parentOf"? I think it is the latter</aside>. In order to delete the "parentOf" link between A and C, we locate IdFacetRelationship objects on A which have the "parentOf" property, and which have C as the relationship target. Yes.
In Case 2, A has a set of attributes, two of which are named "parentOf" <note>the parentOf attribute has, as a field, the target IdFacet</note>. In order to delete the "parentOf" link between A and C, we locate the attributes on A which have the "parentOf" name, and which have C as the relationship target.
Got it. So stored on A are: (“parentOf, “B”) and (“parentOf”, “C”).
So in my view it takes no fewer or more steps to locate the parentOf relationship between A and C in either case.
Well that’s true, but what this model doesn’t allow is that the link itself have properties. This is what I was trying, perhaps not well, to say below when I said “…what's driving things is a desire to consider the link between two objects to itself be an object (with properties on the link)” (emphasized text added).
For example we have a use-case where we need to be able to state the duration for which the link is valid—specifically a from…to duration (in time). With Case1 you simply add two property/value pairs to the link: (“from”, <datetime>) and (“to”, <datetime>). With Case2 I’m not sure what you do…doable no doubt, but trickier.
Part of what is foggy for me in seeing the differences has to do with the structure (syntax) of an Attribute. I'm used to an attribute being of some type. The type can be simple (bool, int) or complex. As long as we have a 'relationship' attribute type, it seems like we can easily index all the relationship Attributes in order to distinguish them from all the other Attributes held by an IdFacet.
Yes. I know what you mean. But just to argue the other side, it is very common in object models to distinguish between attributes (information that is an intrinsic internal characteristic of that object) and relationships (links to other objects that are more external, arms length). And all we’re doing is taking a page from semantic networks and promoting these relationships from being mere “pointers” to being full objects that in turn have intrinsic internal characteristics or “properties”.
What I’m trying to show in adding properties directly to the links in Case2 is that this formalism is more convenient than Case1 (especially for situations where you are dealing with lots of links between objects and you want to adorn these link-relationships with metadata (e.g. link strength, weight, from…to, etc.)). I’m not arguing that Case1 vs. Case2 are different in semantic expressiveness.
Jim
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)?
|