Modeling LID--Planning
From lid.netmesh.org
Contents |
- Head page: Modeling LID
- Next page: Modeling LID--Test first
Modeling LID--Planning
The approach
The approach I will take to building this model will be: specific example > generalization > test by a second specific example > correction or expansion of generalizations > ...
Starting with vCard as the first specific example.
RFC 2426 specifies the version 3.0 vCard fields. Each of these fields carries some identity data about the person offering the vCard. That is to say, each field offers a value (or values) for some property of that person: either a unary property, such as a name of that person, or an n-ary property, such as the role of that person in some organization. (OK, there can be objection to my use of 'property' here; the next paragraph will let you know where i am coming from.) I'll also look at an XML and an RDF format for vCards.
A successful test of an existing model
The current development version of NetMesh includes a generic model of properties. This model enables specifying properties, including type data about values of properties, by populating the generic property model with data. So my first idea was to use this model, providing the data necessare for a model of vCard identity data.
Well, that turned out to be what we call a successful test! The attempt revealed that the property model makes the laughable assumption that a property satisfies only one type. (That may seem a reasonable assumption to a programmer: programming languages have, for practical reasons, a simple type system, in which an item satisfies only one type (and, in some languages, (and, when the programmer follows the Liskov-Wing principle,) the supertypes of that type).)
Of course, a model in which items may satisfy more than one type can be built under the restriction that each item must have a single type. The famous academic example is the classification of persons according to the subtypes, Faculty and Student. A solution is multiple inheritance: teaching assistants satisfy a new type that is a subtype of both Faculty and Student. The result, sadly, is an explosion of types.
For example, the seven types of vCard delivery addresses (domestic and international, postal and parcel, home and work, and preferred) generate as many as one hundred and twenty eight distinct types (at the very least sixteen). Example: my single vCard delivery address is of type, DomesticInternationalPostalParcelHomeWorkPreferred. (Yes, domestic and international are defined as alternatives. I'm stubborn, though, and want to use the same address for both. (My stubborness is related to the reason that the telephone country code for USofA is one.))
So: What's the next step? One possibility is to consider how to fix the existing property model. Another is to make a fresh start. Making a fresh start, using the vCard example, suits the approach announced at the top of this page. (After we learn something from this work, we can go back and work on the NetMesh property model.) So here goes.
The current plan
The plan is to specify a small number of generic classes and associations--needed to model a vCard, but not specific to vCards. To accomplish this by relegating all vCard specific specifications to objects and links of the model.
That is, the model of vCard data will not limit itself to classes and associations, but will expand the modeling armamentarium to include objects and links.
Please contribute.
- Next page: Modeling LID--Test first
