From MWCSWiki

Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page

Back <hr> An object, in and of itself, does not have any data, other than a globally unique URI and perhaps a probably-not-unique name. Data is only associated with the categor(ies) that the object assumes. Example: it is not true that "Abraham Lincoln" was 6'5" tall, but rather that "Abraham Lincoln the Person" was 6'5" tall.

An object, in and of itself, does not have relationships to other objects. All relationships are from one category-of-an-object to another. Example: it is not true that "Abraham Lincoln" was elected in 1861, nor that "Abraham Lincoln" was married to "Mary Todd Lincoln." Rather, "Abraham Lincoln the President" was elected in 1861, and "Abraham Lincoln the Spouse" was married to Mary Todd Lincoln.

Since these two things are true, it begs the question: workflow-wise, does the user add relationship types within the context of a category? Or in a global context? In other words, if I want to add the information that "Lawyers can try cases," do I (a) go to the "edit lawyer category page" and add a relationship type called "tried" to the "case" category, or (b) go to the global "view/edit/add relationship types page" and add a relationship type from there?

Relationships are bidirectional: when someone adds a relationship from one category-of-an-object A to another category-of-an-object B, implicitly B will also have an "inverse" relationship to A. (Whether this is explicitly stored in the database, or only inferred at hydration time, is undecided.)

The term "concept" is a general term that subsumes three specific subtypes: categories, relationship types, and (semantic) objects. Things that are not considered "concepts" are atomic fields and relationships.

A field of a category must be able to possess the following features: name (unique only within the category), type, unit type, and cardinality. For instance: in the "physical object" category, we might have [ height, float, length, 1 ] and in the "person" category we might have [ emailAddress, string, (none), * ].

Open question: are relationships really just the same thing as attributes, in which the object on the other end of the relationship is essentially just an attribute value? (And does the fact that relationships are bidirectional affect this?) <hr> 1/18/08 11:57 AM - Trillane<br />

I would hazard that relationships can be conceptually thought of as attributes and that storing them as such isn't a bad idea. I feel that the hesitancy in this case boils down to a natural and very human distinction between hard data (i.e. height = x inches) and relationship data (high school attended = A.C. Reynolds) because relationship data necessarily points to another object and we feel that they should be different. However that is just semantics (pardon the pun). The truth is that it isn't different. We could just as easily model relational data as static data. For example:

President Category:<br /> Field -> Elected In = 1861 Gregorian Year<br /> Field -> Political Party = Republican Party<br />

and that would be absolutely fine in most cases. The goal of this project is to improve on static data, and that's why we would say 1861 isn't just a number in an int field, it's really it's own object with it's own categories and data that we can now link to.

The goal, and somebody correct me if I'm wrong, in having "relationships" is really just data integrity and category linking. We don't think Elected In = Water Bottle makes any sense, so we don't allow that. We also now know that in the object 1861 a president was elected, as well as there was a president object and he was elected in 1861 so those two categories are now related and therefore searchable. The relationships are what connect (like a web) the categories together.

On the visual aspect, displaying the information would depend entirely on the client (i.e. Fred Museum), but for now, it might be easier to say relational fields would contain whatever link or pointer to another object, and then the display would pull up the human readable name for that object. And of course static fields would just return their values.

As far as conceptual storage is concerned that's tricky and will require some thought. Maybe a series of order line tables, or force double data entry, for example, if someone creates a "vetoed" relationship between presidents and bills, then they would also have to name a relationship (hopefully) "vetoed by" that would link bills and presidents. Something to think about.

Or we could change what we think of bi-directional, (not that it isn't bidirectional) We tend to think of things from left to right. Lincoln Object "elected in" 1834 Object , and then feel compelled to say 1861 Object "the president that was elected was" Lincoln Object. Because we think that bi-directional means president category to year category for Lincoln, and year category to president category for 1861. Maybe we could have a switch with the field, that would indicate the "direction of the relationship". For example the president category would have a field "Elected In" and it would point to 1834, and the switch would be left to right, so it would be (current object)"Lincoln" "Elected In" (pointer to object) "1861". Then in the year category for 1861 it would say "Elected In" (pointer to object) "Lincoln" with the switch set to right to left so pulling up the information would say (pointer to object) "Lincoln" "elected in" (current object) "1861". Let me know if that was total gibberish and or not useful.

I do feel that for searching purposes both categories should somehow reflect the relationship in the database.

That's all I have for now. :)