Okay, we’re
in sync now. For the record I’ve re-corrected the last two.
-----Original Message-----
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, March 29, 2006
2:11 AM
To: higgins-dev@xxxxxxxxxxx
Subject: RE: [higgins-dev] Higgins
data model
In regards to your correcting my mixup between Case 1 and
Case 2 near the end, you got all the corrections right except the last
two. There, I meant to say that I want to believe there is added convenience in
the relationship/link case (Case 1), but I'm not seeing it yet. I should have
given these better names like Rel+Attr vs PureAttr
Jim
>>> On Tuesday, March 28, 2006 at 8:32:46 pm, in message
<011201c652e1$724b8930$9601a8c0@VGCRB30>, "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx> wrote:
See green below.
Jim wrote:
>>> On Tuesday, March 28, 2006 at 4:51:29 pm, in message
<00f201c652c2$88b51660$9601a8c0@VGCRB30>, "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx> wrote:
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").
That
would be a simplistic representation. More likely it would be like:
(name = "parentOf", type =
"relationship", relatedTo = "B", validFrom =
"200603281200", validTo = "200603281800", lastVisit =
"200601151433" )
(name = "parentOf", type = "relationship",
relatedTo = "C", validFrom = "200603161200", validTo =
"200604161200", lastVisit = "200602231200" )
In this
case, the fact that the attribute type is "relationship" indicates
that there will be a "relatedTo" field and possibly other fields
(like the ones I threw on there).
As I mentioned in my email just now to Tom, now that I see what
you've written above, the differences between Case 1 and Case 2 are small.
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.
See
above example, and also note that an attribute's value(s) (at this point at
least) can be any object. We haven't gotten that far yet, but I'm assuming
we're not constraining attribute values to strings or other simple types.
Right. This is the key point. If we assume compound Attributes
that consist of, say a sole "name" property (with value) and N other
arbitrary properties then an Attribute looks a lot like a Relationship.
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".
Yes, I
assumed (based on earlier mentions of RDF) that this model has some roots
in that world. I'm just trying to see the compelling reasons for one
model over the other. I sometimes wonder if the creators of XML had the same
kinds of discussions (regarding attributes and sub-nodes).
Let's hope we do better than the XML folks. They provided
different ways to express the attribute concept and offered no guidance as to
which syntax to use. The result is far less interoperability than there could
have been. In XML should you say <Tom parentOf=Evan/> or <Tom><parentOf>Evan</parentOf></Tom>
? Nobody knows the answer. My takeaway is that we should only provide one way
of expressing attributes and one way of expressing relationships. IMO a single
object in XML should ALWAYS be expressed as a single element, e.g. <Tom
attr1=val1 attr2=val2.attrN=valN>
Frankly,
I've wrestled with the two models in my mind, trying to make analogies to the
real world, and I never land squarely on one side or the other. At this
point, I see your paragraph above as the compelling reason for Case 1, and for Case 2 I see two
reasons: a) It matches the model used by at least one potential data
store (X.500/LDAP), b) It reduces the number of classes and in my sort of
minimalist mind, that's a good thing.
What I'm trying to show in adding properties directly to the links
in Case1 is that this formalism is more
convenient than Case2 (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.
I want
to believe there is added convenience in Case 1 I just haven't had that aha! moment yet. I couldn't explain the
benefits of Case 1 to the next guy that comes along with the same questions.
Argggh.. I think we got 1 and 2 mixed up in the last three paras
above (only these 3). I've corrected in green. Hope this is what you meant. I
think it is. Double Argggh. Refixed in purple
in previous para.
>>> paul@xxxxxxxxxxxxxxxxx 3/28/06 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?
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/24/06
2:08:01 pm >>>
|