| RE: [higgins-dev] attributes vs relationships (was Higgins data model) |
|
Hi Jim,
You present a scenario where Case 2 wins. But I think that was an unusual scenario. I think that the attribute/relationship distinction is clear and obvious most of the time. Do you disagree?
On a somewhat related matter…
Your use of the word type (as in type = “string”) is interpreted by me to mean “the type of this attribute’s value”. Yet I would have expected that the value of an attribute was an object whose type was discoverable through reflection. In other words I would have expected you to write your examples like this:
{name = “interest”, “B-Movies”}
where “B-Movies” was a String object. Is this an implementation-related issue, is this just common practice in directory work. Or am I just missing something entirely?
(Further, I’m hoping that “interest” is really a URI like “http://foo/bar/baz/interest”)
-Paul
-----Original Message-----
After reading this, I dislike the word "like" as
used. replace it with "interest" and it reads better (purely
aesthetic). One example that I have a hard time making fit into what I previously called "Case 1" is where an attribute is sometimes a link to another facet and other times not.
Say I want to represent my likes. I see this as an attribute. For example, I could list:
{name = "like", type = "string", stringVal = "B-Movies"} {name = "like", type = "string", stringVal = "Skiing"} {name = "like", type = "radioStation", callLetters = "KRCL", band = "FM", frequency = "90.9", preferredDJs = {name = "The Old Man", name = "Robert Nelson"}}
But hold on, I happen to note that there already exists another facet in my context which represents KRCL (the radio station). Rather than typing all that garbage into the attribute on my facet, I'd prefer to link to it. Of course, *only* linking to it causes me to lose my "preferredDJs" list. So now I want to associate a property with the link. Both Case 1 and Case 2 allow for this. The difference as I see it is that Case 1 now causes my list of likes to be spread across my attributes and relationships. The modified Case 2 follows:
Jim { Attributes { {name = "like", type = "string", stringVal = "B-Movies"} {name = "like", type = "string", stringVal = "Skiing"} {name = "like", type = "radioStationRelationship", relatedTo = "xyz://myContext/KRCL", preferredDJs = {name = "The Old Man", name = "Robert Nelson"}} ... } }
Case 1 looks something like:
Jim { Attributes { {name = "like", type = "string", stringVal = "B-Movies"} {name = "like", type = "string", stringVal = "Skiing"} ... }
Relationships { {type = "like", from = "xyz://myContext/Jim", to = "xyz://MyContext/KRCL", toType = "radioStation", preferredDJs = {name = "The Old Man", name = "Robert Nelson"}} ... } }
The interrogator of my likes in Case 2 enumerates the "like" attribute types, discovers their types, and processes. In processing a "relationship" type, it must dereference the target facet and add the appropriate properties.
The interrogator of my likes in Case 1 enumerates the "like" attribute types, discovers their types, and processes. Then enumerates the "like" relationship types, and for each, dereference the target facet, discovers its type, processes data from that facet, and adds the target facet's properties to those on the link.
Note that I added toType to the relationship. This was to avoid having to dereference the target facet in order to know what properties to expect on the relationship object. Similarly, I used type = "radioStationRelationship" in Case 2. Both cases can be simplified (type = "relationship" in Case 2, and remove the toType in Case 1), but that causes the interrogator to dereference the target and read it's type to know what to expect in terms of further properties.
If the group prefers Case 1 over Case 2, how can we make this example less awkward? I don't really like going the other possible direction to fix it (make facets for B-Movies and Skiing, and any other potential "like" out there).
Jim |