| [higgins-dev] attributes vs relationships (was Higgins data model) |
|
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 |