You forgot the extra IdRelation = IdRelationship2a and IdRelation = IdRelationship2b on Tom, as well as these (assuming you don't coach Angus yet):
IdRelationship = IdRelationship2a relatedSubject = Angus type = parentOf
IdRelationship = IdRelationship2b relatedSubject = Angus type = legalGuardian
>>> On Tuesday, March 28, 2006 at 5:06:19 pm, in message <44296D0B.0A7A.00E4.0@xxxxxxxxxx>, TDoman@xxxxxxxxxx wrote:
Hmmm, I thought that you were saying that the Tom object would have no reference the link objects whatsoever. That the relationships would be discovered by a query on an index specifying, in this case, from=Tom, etc. This is what I thought you were saying would eliminate some of the complexity since the Tom object would not have to be visited to remove a relationship property. So, Jim's Case 1 is missing at least one step.
I can see how having a relationship object would be beneficial where the same relationship exists among many objects ... maybe your correction of my example is doubly linked and shouldn't be (Tom has "hasRelationship" and Link 1a has "from") ... I'll add another child to the mix in the example ... I'm out of sons but I'll pretend I got that 3rd child I always wanted, let's say another son ... Angus. ;) Basically, I'd just eliminate the "from" property from the link.
Evan: hasRelationship - Link2
Angus: hasRelationship - Link2
Link 2: to - Tom type - son
Maybe this matches what Raj is trying to show in the diagram. Let me map the example:
Digital Subject = Evan IdRelation = IdRelationship2
Digital Subject = Angus IdRelation = IdRelationship2
IdRelationship = IdRelationship2 relatedSubject = Tom type = son
Digital Subject = Tom IdRelation = IdRelationship1a IdRelation = IdRelationship1b IdRelation = IdRelationship1c
IdRelationship = IdRelationship1a relatedSubject = Evan type = parentOf
IdRelationship = IdRelationship1b relatedSubject = Evan type = legalGuardian
IdRelationship = IdRelationship1c relatedSubject = Evan type = soccerCoach
Is this right? So, if most of the relationships in the system are unique, this could actually increase the complexity. If most of them are shared, this could really decrease it. Now, if a "relateeSubject" was added to IdRelationship, the "from" property from the original example, the maintenance of the reference between related objects could be eliminated. This may add another level of complexity not to mention that I'm not sure how well this data model maps onto data models we want to operate in. Did I get your intent correct Paul, Raj? If so, does anyone care to map this to a directory model?
Tom
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/28/2006 4:26:27 pm >>> 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
Link 2:
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
>>> paul@xxxxxxxxxxxxxxxxx 3/28/2006 12:37:39 pm >>>
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
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/24/06 2:08:01 pm >>>
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)?
_______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|