[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: the <data-about> element
Upon reviewing our method of explaning of the <data> element, I recommend that we revise our language to eliminate a confusing sense of the word "subject". Almost the entire explanation can be re-phrased without changing the DTD, but one small change would be required. The sub-element for the <data> element would have to be renamed. The sub-element has an attribute that provides a URI for an object, and then has content that describes that object. My proposal is to call the sub-element <data-about>. In a pool of topics, an important activity is to try to capture what things are about. We sometimes use a very specific sense of the word "subject" for that work. We introduce objects that specify a subject, and then link to those objects in order to tag content with that subject. Without this change, there will be a sense of subject built into the DTD that is very different from the sense that is used when associating a tag with a topic. For those who are comparing with previous explanations the rewrite is to substitute "value" for "object" and "object" for "subject". But, fair warning, reading the discussion below the "=====" will probably be easier than trying to transpose terms in existing explanations. Could we address the proposed sub-element renaming at the next TC meeting? A decision in favor of a renaming could be made quickly if TC members find the following method of explaining the <data> element helpful, or if we have no strong advocates for the existing element name (<data-subject>). Best wishes, Bruce Esrig Information Architect, Information Products and Training (IP&T) Lucent Technologies, 67 Whippany Road Room 1A-158, Whippany, NJ, 07981 +1 973 739 1235, esrig@lucent.com ==================== The following narration is about an example set provided by Erik Hennum. The <data> element allows us to associate a property that has a particular value with an object. <containerAndObjectElement> <data name="propertyName">propertyValue</data> </containerAndObjectElement> In addition to allowing the value as content, the <data> element provides a couple of attributes for expressing the value: * Where the value is text, you can use the value attribute instead of textual content. That's especially useful when you need to enumerate the possible values. * Where the value is identified by a URI, you use the href attribute to supply the URI. <data-about href="objectURI"> <data name="propertyName">propertyValue</data> </data-about> For complex data structures, the data element can nest: <containerAndObjectElement> <data name="propertyName"> <data name="subpropertyName">subpropertyValue</data> ... </data> </containerAndObjectElement> For the case where the value of one property is the object of another (as with the listing that has a broker who has a phone number), the <data> element can nest the <data-about> element: <containerAndObjectElement> <!-- the listing --> <data name="propertyName"> <!-- the property is hasBroker --> <data-about href="valueURI"> <!-- points to the broker object --> <!-- supplement the broker object with a phone number --> <data name="subpropertyName">subpropertyValue</data> </data-about> </data> ... </containerAndObjectElement> If you only needed to capture that the listing has a broker, you could just use the URI for the broker, as in: <containerAndObjectElement> <!-- the listing --> <data name="propertyName" href="valueURI"></data> </containerandObjectElement>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]