| RE: [higgins-dev] attributes vs relationships (was Higgins data model) |
|
Replies in red >>> On Wednesday, March 29, 2006 at 9:23:23 am, in message <01e601c6534d$19bb4b90$9601a8c0@VGCRB30>, "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> wrote: 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? I'm not sure. I do know that in the world of directories, all relationships but one (hierarchy) are modeled via attributes and that even the built in Hierarchy mechanism only adds confusion (could have/should have been done with attributes). That's not to say I want the model to behave just like a directory, just anecdotal evidence. FWIW, I wasn't trying hard to contrive that example, it's more that I have the feeling that this kind of thing will come up over and over where people will start out using attributes for something, and later find they need to switch over to using relationships in order to minimize data duplication. Actually, thinking about it more, I think the example is pretty common. At livejournal.com (and I imagine other blog sites as well), one can list their interests. If an interest is shared by another user, or if there's a community for that interest, then a relationship (link) is formed. If not, the interest is only simple text. How is it stored in the back-end? I dunno for sure, but I suspect not as two quite different sets of data.
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? Not being sure how attributes are going to be typed in the higgins model, I only did that as a means of clarification. With directories, each named attribute has a separate schema definition which dictates its form. One has to use the attribute identifier to go look up the schema definition to discover the type/form (or just have a-priori knowledge of that attribute's type/form). If higgins proposes to use reflection, we better make sure that the target programming languages support it (do we have a list of target programming languages yet?). (Further, I'm hoping that "interest" is really a URI like "http://foo/bar/baz/interest") Yeah, that's the problem with writing quick examples, I let side details slide. I think everyone would agree that Attribute identifiers need to be unique (and a URI is one good way to do that). -Paul So, I'm not sure where we are with this. If we stick with Case 1, we can decide to ignore it, or we can state that all values of an attribute must be of the same type, and if that type has a need to (always or sometimes) link to another facet, it really should be a relationship. Here's what I see as the rub in Case 1. As long as there's a way to "point at" another facet (using it's identifier for example), then there's nothing to stop anyone from coming up with an attribute (complex or simple) which has as a field, a facet pointer. Once that practice is established, it will be confusing to know when to do that versus using relationship objects. What prevents this kind of confusion in the graph-world? Jim -----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 |