[
Lists Home |
Date Index |
Thread Index
]
Roger--
To echo a previous comment, it seems to me you're largely (if not
entirely: I haven't been following this that closely) reinventing RDF,
with somewhat different syntax. It might help to clarify things to look
at whether RDF's *model* (basically, things having identity, plus
properties describing those things) does what you want, and it's the RDF
*syntax* that's the problem, or whether there is something more
fundamental going on.
Note that Naz's approach isn't any less RDF than the other ones. Your
example
>
> <Person id="RLC>
> <Name>Roger L. Costello</Bag>
> <HairColor>red</HairColor>
> <SSN>310-60-1234</SSN>
> </Person>
effectively uses what RDF would call a "typed node" (the PERSON tag),
while Naz's approach substitutes the notion of a "bag" for a (not
explicitly typed) RDF resource, and uses
<is-a instanceOf="Person"/>
as an explicit "type" property, where RDF would say something like
<rdf:type rdf:resource="...some URI prefix...#Person"/>
--Frank
Roger L. Costello wrote:
> 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
>
>
|
