[
Lists Home |
Date Index |
Thread Index
]
A names record with a Master Names index is the most common
approach in records management systems now. (Hint: the index
is part of building relationship models so a name can be used
in multiple record types).
Hair color is not immutable. Nor is hair. You'll find out.
Transient properties have history files (your address will,
your hair color will; your eye color won't). One advantage
of any broadcast approach is that it is a snapshot and a
reason to insist on timestamps and even rate of change information.
The property bag approach is the midway approach to full up Groves.
Slowly but surely, the Hytime guys are winning. :-)
len
From: Roger L. Costello [mailto:costello@mitre.org]
Hi Folks,
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.
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>
and many, many other ways.
Thus, many different types of objects may have the same properties.
4. The properties may be aggregated with other type-specific
properties. For example, the Employee type may have a specific
property called EmployeeID:
<Employee id="RLC>
<Name>Roger L. Costello</Bag>
<HairColor>red</HairColor>
<SSN>310-60-1234</SSN>
<EmployeeID>10981</EmployeeID>
</Employee>
5. The type of an object may be inferred simply from the aggregation
of properties. For example, if I told you:
"The object has 4 tires and a steering capability."
You might infer that the object is an automobile. If I told you:
"The object has 4 tires, a steering capability and wings."
You might infer that the object is an aircraft.
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.
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.
8. Consider the coupling of a Person object and an Auto object:
<Person id="RLC>
<Name>Roger L. Costello</Bag>
<HairColor>red</HairColor>
<SSN>310-60-1234</SSN>
</Person>
<Auto id="RLC-Avalon">
<Model>Avalon</Model>
<Make>Toyota</Make>
<Year>2004</Year>
<DrivenBy href="#RLC"/>
</Auto>
Note how the Auto object references the Person object
using <DrivenBy href="#RLC"/>
This defines a "static" relationship between the
Person object and the Auto object. I am "hardcoding" a
dependency between these two objects.
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.
For example, here's how to express information about Roger L. Costello
and his relationship to The MITRE Corp.
<bag id="RLC">
<is-a instanceOf="Person"/>
<has property="Name">Roger L. Costello</has>
<has property="HairColor">Red</has>
<has property="SSN">310-60-1234</has>
<refersTo xlink:role="employed-by"
xlink:href="#MITRE"/>
</bag>
The way to read this is,
"This is information about an object which has three properties - Name,
Age, and SSN. The type of the object is 'Person'. It is related to
another object (MITRE) by the relationship, 'employed-by'."
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.
Here the Name, HairColor, SSN properties are associated with an
"Employee" type and a "Person" type:
<bag id="RLC">
<is-a instanceOf="Employee"/>
<is-a instanceOf="Person"/>
<has property="Name">Roger L. Costello</has>
<has property="HairColor">Red</has>
<has property="SSN">310-60-1234</has>
<refersTo xlink:role="employed-by"
xlink:href="#MITRE"/>
</bag>
So properties are things that can be aggregated, typed, and related to
other objects ... dynamically. In a large, dynamic system this agility
is crucial (I assert). This is called "opportunistic composition and
relationships".
In my last message I issued a challenge: how can simple vocabularies be used
to construct an Invoice for the purchase of a Book. Here's how to implement
the Invoice using Naz's approach:
<bag id="RLC">
<is-a instanceOf="PostalAddress"/>
<has property="Addressee">Roger L. Costello</has>
<has property="Street">38 Boylston St.</has>
<has property="City">Boston</has>
<has property="State">MA</has>
<has property="Zipcode">01320</has>
<refersTo xlink:role="purchased"
xlink:href="#Bach"/>
</bag>
<bag id="Bach">
<is-a instanceOf="Book"/>
<has property="Title">Illusions</has>
<has property="Author">Richard Bach</has>
<has property="Date">1977</has>
<has property="ISBN">0-440-34319-4</has>
<has property="Publisher">Dell Publishing Co.</has>
<refersTo xlink:role="purchased-by"
xlink:href="#RLC"/>
</bag>
<bag>
<is-a instanceOf="Invoice"/>
<refersTo xlink:role="contains"
xlink:href="#RLC"/>
<refersTo xlink:role="contains"
xlink:href="#RLC"/>
</bag>
The advantages of the Bag approach are:
1. Opportunistic composition and relationships.
2. Highly scalable.
3. Well-suited in cross-domains.
4. Well-suited in evolving systems.
5. A flexible, dynamic Web of data is created.
The disadvantages of the Bag approach are:
1. It requires more skill to build applications because
properties and relationships are not fixed. We are
all comfortable with writing applications that can
process this:
<Person>
<Name>Roger L. Costello</Bag>
<Age>39</Age>
<SSN>310-60-1234</SSN>
</Person>
But it is much more challenging to write an application
that can process a {Name, Age, SSN} collection which in
one part of the system represents a Person, in another
part of the system represents an Employee, etc.
Further, the relationships between this object and other
objects may dynamically change (see observation #6 above).
2. A flexible query and navigation language is required. The
language must allow navigation based upon dynamically
established relationships. For example,
"[From the Person object] Navigate to the "driving" object."
See Observation #6 above. Unfortunately, XPath provides a
fixed (static) set of navigation capabilities - child, ancestor,
preceding-sibling, etc. [I assert] These are inadequate in a
large, dynamic system.
Comments? /Roger
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
