[
Lists Home |
Date Index |
Thread Index
]
Roge Costello wrote -
> Yesterday I received an approach from Naz Irizarry. His approach
> has some similarities with Peter's approach.
>
> Before describing Naz's approach let me make some observations
> about this simple XML object:
>
> <Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> </Person>
>
> OBSERVATIONS
>
> 1. The above XML represents information about a Person "object" with
> Name, HairColor and SSN "properties".
>
> 2. The Name, HairColor, and SSN properties are "physics". That is,
> they are basic, immutable aspects of an object.
Ha! My daughter hsa a friend who has brown hair,e xcept that this year it is platinum with purple streaks. My wife's legal name changed after she married me. Even SSNs cn be changed (in special circumstances). Immutable, my foot!
>
> 3. These properties could be used by many objects. For example,
> they could be used to describe an "Employee":
>
> <Employee id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> </Employee>
>
> or they could be used to describe a "Student":
>
> <Student id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> </Student>
As always, your questions deal with modeling. If you regard a Student or an Employee as a thing in itself, you run into these kinds of difficulties. It is better to regard them as roles that a person may play from time to time. Then most of these issues basically go away.
> 6. In the real world relationships between objects change. For example,
> when I drove to work this object:
>
> <Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> </Person>
>
> established a relationship to this object:
>
> <Auto id="RLC-Avalon">
> <Model>Avalon</Model>
> <Make>Toyota</Make>
> <Year>2004</Year>
> </Auto>
>
> Namely, the relationship established was:
>
> "The RLC Person is driving the RLC-Avalon Auto."
>
> Once I got to work that relationship ceased to exist.
> Thus, it is useful to provide for dynamic relationships.
If you want to assign charcteristics to a relationship, dynamic or not,then you have to make the relationship into a thing (rdf resource or bnode) so you can refer to it and give it properties.
> 7. Consider again the Person object:
>
> <Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> </Person>
>
> This XML defines a "static" relationship between the Person "type"
> and the Name, HairColor, and SSN "properties". That is, by nesting
> <Name>, <HairColor>, and <SSN> within <Person> I am "hardcoding"
> a dependency between the <Name>, <HairColor>, <SSN> properties and
> the <Person> type.
Or alternatively, it defines a dynamic relationship that holds just at the current time.
> 9. I will stipulate that in large systems "agility" of data
> is important:
> - At "run-time" it is useful to be able to
> aggregate properties and denote them to
> be of a particular type.
> - At run-time it is useful to be able to
> extend the properties of an object.
> - At run-time it is useful to be able to
> add relationships from one object to
> another object, and to be able to
> remove relationships.
>
> With the above observations in mind, I am now ready to
> present Naz's approach.
>
> THE NAZ IRIZARRY APPROACH
>
> The key feature of Naz's approach is the Bag. Think of a Bag as an
> "object". An object has "properties". An object has a "type". And an
> object has "relationships" to other objects. Thus, a Bag has three parts:
>
> 1. A collection of data (these are the properties of the object).
> 2. An indication of the type (the type of the object).
> 3. Relationship information.
>
There is nothing particularly different here - just because you call a container a "bag" doesn't really change anything.
> For example, here's how to express information about Roger L. Costello
> and his relationship to The MITRE Corp.
> With the Bag approach properties are dynamically composed. The
> same properties can be associated with a different type. Further, the
> properties can be associated with multiple types.
>
You can do the same thing with <person>...</person>, there is no essential difference. It is just syntax, and it is a little more complex and harder to read. It would be better to get the modeling straight about roles and relationships with attributes.
Cheers,
Tom P
|
