[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Higgins data model
|
Hi Tom,
I wasn't trying to imply that the Tom instance would not have a reference to
the link instance. Also, I think that the sharing of relationships instances
(that you thought I meant) will be the exception, not the norm.
Jim has suggested the following more complex "Case 2" for Tom:
(name = "parentOf", type = "relationship", relatedTo = "B", validFrom =
"200603281200", validTo = "200603281800", lastVisit = "200601151433" )
(name = "parentOf", type = "relationship", relatedTo = "C", validFrom =
"200603161200", validTo = "200604161200", lastVisit = "200602231200" )
If that is what you and Jim mean by attributes then the differences between
Case 1 and Case 2 are much smaller than I thought.
Raj has to some of us suggested that DigitalSubjects like Tom have two
parallel methods 'getAttributes' and 'getRelationships'. If instead of using
(...), as Jim has above to display the returned Attributes, I instead use
{...} to show the returned Relationships, then "Case 1" would be:
{type = "parentOf", relatedTo = "B", validFrom = "200603281200", validTo =
"200603281800", lastVisit = "200601151433"}
{type = "parentOf", relatedTo = "C", validFrom = "200603161200", validTo =
"200604161200", lastVisit = "200602231200"}
These two Relationship instances have a set of properties on them: type,
relatedTo, validFrom, validTo, lastVisit. [We could decide to doubly link
things by including a relatedFrom property too, but let's not go there right
now]. This is nearly the same set of properties as the two Attribute objects
returned in Case 2 above: name, type, relatedTo, validFrom, validTo,
lastVisit.
So now we're down to the following subtle differences:
Relationship links to other DigitalSubjects are:
Case 1: compound Relationship instances returned from 'getRelationships'
Case 2: compound Attribute instances whose type="relationship" from
'getAttributes'
Relationship links have a "type" notion that is:
Case 1: the value of a "type" property
Case 2: the value of a "name" property
The data model minimalist will say "get rid of Relationships, because as you
can see above you can do it all with compound Attributes". The person who
has spent a lot of time looking at node-and-edge graphs and likes to have
edges (relationships) be explicitly in the model and be able to attach
arbitrary properties to them. They might even want to be able to create
their own subinterfaces of Relationships (beyond ContextRelationship and
IdRelationship as Raj has done).
My biases make me prefer Case 1. But I can certainly see that if in some
applications where links are not so common and/or important, the simplicity
of the "pure Attribute" approach would appeal.
Tom 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
