[
Lists Home |
Date Index |
Thread Index
]
BTW, that's also called a 'stored procedure'.
Yes, links/relationships that aren't hardwired to particular
instance values can be functions or queries.
In many applications, that can be what the URI identifies.
A table schema IS a simple vocabulary. That's what normalization
is all about.
It isn't that magic isn't useful; it is that it is so
unreliable and seldom necessary.
len
From: Roger L. Costello [mailto:costello@mitre.org]
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
|
