From MWCSWiki

UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY

Objects and Relationships

I'm still working on the page interaction diagram that I'm going to post hopefully later this week. Which is the catalyst for my current thoughts. The way we have objects and relationships currently modeled is that (ignoring pairable for the moment, as that is fine) is that an object aggregates roleplayers which then aggregates relationships and field values. Yet we talked about having a relationship page that in theory would have roleplayers that would aggregate relationships and field values. Yet there is no reflection of roleplayer capability in our current domain (and as a result, presentation) however the database schema is already in place.

What we do allow are objects that are really relationships. We can create a Revolutionary War "object" which can also be modeled as (America as a Colony <u>fought</u> Great Britain as Nation) <u>over</u> Taxation Without Representation as a bad thing. Which is as it should be, most users are not probably going to start out thinking of things in this manner. What we don't allow is the other transition, I have this relationship, and now I want to talk about it as an object. In order to do so, we force them to create an actual object, because we can't currently add roleplayers to relationships. If that is what we want them to do, then we can do that. In which case there is no "relationship" page, it's actually an object page that has the title of a relationship. Which brings me to my point.

Relationships are objects.

Not in the physical sense, of course, but in how we are modeling our data. They already have a name and uri (yes, I know all concepts do), they just happen to have more information attached to them, initially, than objects. They can appear on either side of an "action", either side of a pairable, and can have roleplayers with associated relationships and field values (at least in so far as we have talked about them). Which is, well, identical to an object.

--Trillane 20:47, 14 May 2008 (EDT) Now I've been doing some more thinking. Maybe the default name of a relationship is the action (what normally shows up on either side of another relationship). And then we allow the user to rename it. If it gets renamed, it gets "promoted" to an object, whereupon it gets roleplayers etc. Though that's a bit tricky, as you still want other relationships with a part of the promoted relationship to still show up other places. Something to think about.

--Trillane 19:36, 15 May 2008 (EDT) Why do you objects have to have roles to have a relationship, but not relationships? Why wouldn't a relationship in a relationship (on either side of the action) not need a roleplayer?

--Trillane 09:10, 17 May 2008 (EDT)I understand that currently the schema involves assigning the action as the "role" in relationship on either side of a relationship (i.e. modebinding). And in most cases this is sufficient (i.e. married to would probably only have one role "marriage" and I agree it seems redundant to add that "twice" as it were), however a complex relationship may have a few different aspects that may not be as clear when associating itself with another relationship. For example it may be possible to end up with this relationship in the database:<br /> Allies as an Alliance <u> fought </u> Axis as an Alliance <br /> And this relationship would play different roles depending on the context of the relationship it's being attached to.(as an Inspiration, as a War, as Vehicle For Scientific Achievement, etc)

Of course you could argue that user would have just created a WWII object and that is exactly my point, what if they didn't start with "top down" approach, but started from "the bottom", as it were, and wanted to add pertinent information to a relationship.

While we allow the addition of field values and relationships to a relationship, we don't allow meaningful grouping (or division) of data and we don't support extending the schema within a relationship.

I guess my current thought on changing this would be to let relationships extend object, and automatically give them one roleplayer (the action associated with the relationship) as the default. This would then be the default role when associating with another relationship. If the user adds more roles, then they would get to choose. This would also make several classes in our domain redundant, and in a way (once revised) will simplify our system. The change would not affect the database schema in a meaningful way (if at all).