[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A Systematic Approach to using Simple XML Vocabulariesto I
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 > >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|