Data Consortium Standard Practice

Named Value Notation

Proposed Standard - February 02, 2002

This version:
http://www.dataconsortium.org/documents/NamedValueNotation/V0.9
Authors:
John McClure

Abstract

The Named Value Notation is a semantically-oriented convention for tagging information within xhtml and other xml files. It builds on W3C standards, primarily xml Namespaces, XPATH, and RDF and RDF Schema; it does not extend these xml dialects. The conventions do extend the European Computer Manufacturer Association standard for scripting languages (for example, Javascript), but only in the manner that numeric indexes are handled.

By following the standard practice defined here, all document exchange intended to conform with Data Consortium standards is now exclusively based on the xhtml protocol for physical transport. Although this standard practice specifically accommodates exchanges of documents encoded with non-presentation oriented xml dialects, such exchanges are not recommended for the reasons given below as suitable for standardization by the Data Consortium.

This standard practice is an outgrowth from the development of an RDF Schema-based dictionary of nouns, verbs, and qualifiers used in the commercial real estate sector. As such, the technical design of the dictionary is involved with the description of the technologies used to represent business object models created in support of this industry. An earlier publication -- the Data Consortium Namespace, Document Type Definition Version 1.50, is being re-issued as a physical xml schema associated specifically and only with the Data Consortium's Toolkit of CORBA objects.

Status of this document

This document is a proposed standard for consideration by the membership of the Data Consortium.

Please send comments to John McClure jmcclure@hypergrove.com or to the publicly archived distribution list at http://groups.yahoo.com/group/DCNArchitecture/join or at the Data Consortium Website's Bulletin Board.

Table of contents

1 Introductory Remarks
2 Name Structure

2.1 Datatype Tokens
2.2 Data-entryTokens
2.3 Noun Tokens
2.4 Index Tokens
2.5 Predicate Tokens
2.6 Qualifier Tokens
2.7 Time Tokens
2.8 Namespace Tokens
3 XHTML Markup Rules
4 Linguistic Model

1 Introductory Remarks

Rationale

To facilitate early and easy adoption of standards for xml documents exchanged among Data Consortium members, an approach is adopted that builds upon existing methods, processes, and tools being used today by web applications developers . Today, the building of Dynamic html forms and documents is central to applications development, a fact expected to remain generally true for the near-term future. Given this existing environment, a standard whose success is predicated on a sudden adoption and mastery of new technologies, is one that is likely adopted only after a difficult transition period for all organizations involved, during which the enthusiasm for standards may flag, or even the standard itself may become obsolesced.

Identifying a set of conventions rooted in today's well-understood technologies — conventions which meet our fundamental requirement to extract data from files received from another Consortium member — is the goal achieved by this document. Previously, a Document Type Definition (DTD) for commercial real estate documents was specified, despite the implicit consequence that, in order to participate in standard exchange, an organization needed to learn and adopt new tools specific to the Data Consortium's own, custom, DTD. In practice, this has resulted in significant pushback by Data Consortium members already engaged in creating their own, in-house DTD; by members unwilling to invest in new xml tools or xml training for staff; and by members expecting other (larger) standards efforts by related vertical industries and by horizontal quasi-government consortia to overwhelm the (smaller) standards effort initiated by the Data Consortium.

In light of this, it was imperative to review our development process for "xml standards" with a focus on leveraging members' investment in today's html-based technologies. Creating xml standards in an html world may appear in conflict, however the Hypertext Markup Language has been xml-ified as "xhtml" by the W3C. This means an xhtml file is an xml file; exchanging xhtml files is exchanging xml files; and defining standards for the coding of xhtml is establishing xml standards. Confusing may be that xhtml is still referenced as plain, old "html", when in fact xhtml is backwards-compatible with html browsers. This document, for instance, is in a file whose extension is ".html" even though, internally, it is an xml file, encoded using the Extensible HyperText Markup Language (xhtml).

Technical Synopsis

This document gives a systematic, compact and informal description for the construction of names that can be assigned to textual values within xml files. These names are encoded as the value of an xml namespace-qualified names attribute that has global application, that is, it is an attribute that can be placed onto any xml element. For instance, assuming an xml namespace qualifier dc: has been defined, then the following codings are legal within a well-formed xml file.

<span dc:names='Facility.Name.text'>The White House</span>
<span dc:names='Facility.Resident.Name.text'>John Adams</span>
<span dc:names='Facility.Address.AddressLine.text'>1600 Pennsylvania Avenue</span>
<span dc:names='Facility.Address.PostalCity.Name.text'>Washington</span>
<span dc:names='Facility.Address.PostalDistrict.Name.text'>District of Columbia</span>
<span dc:names='Facility.Address.PostalCode.text'>10001</span>

These names for text content of span elements have tokens which mimic an arrangement of similarly-named elements in a typical xml file. In effect, a name is an XPATH expression that would be used to retrieve the same information from a structured xml file, albeit a "period" rather than a solidus (/) separates the tokens.

<Facility>
   <Name><text>The White House</text></Name>
   <Resident>
      <Name><text>John Adams</text></Name>
   </Resident>
   <Address>
      <AddressLine><text>1600 Pennsylvania Avenue</text></AddressLine>
      <PostalCity><Name><text>Washington</text></Name></PostalCity>
      <PostalDistrict><Name><text>District of Columbia</text></Name></PostalDistrict>
      <PostalCode><text>10001</text></PostalCode>
   </Address>
</Facility>

Benefits

Exchange html Forms and Reports
Systems are more robust when source information is operated upon, rather than derived information. The dotted-name conventions can be placed into html forms and into html reports. There is no need for separate datastreams, one for collecting/displaying information, and another for exchange. There is no need to create an Extensible Style Language (XSL-T) stylesheet to re-format an xml datastream into an html stream suitable for display by browsers. There is no need to create separate html datastreams for display by browsers that are not XSL-capable.

Highly Versatile Convention
The dotted-name convention reduces all information to name/value pairs, the approach of other, well-known, protocols such as comma-delimited files. Because the dotted-names are attributes on xml elements, rather than xml elements, then they can be "carried-along" during cut/paste operations performed by xml-aware clipboards. Because multiple names can be assigned to a single string of text, the convention provides forward-compatibility with changes in one's data models, while eliminating the issue of maintaining consistency between the values of names mappable to one another.

Simultaneous, Multiple, Protocol Support
A single xml file can be annotated with the names from more than one domain simultaneously, therefore the document remains meaningful to each domain without any intervening (loss-y) transformations. For instance, a single span element can be annotated with names from one's internal namespace, with names from the Data Consortium's namespace, and with names from a Legalxml namespace. Such an annotated file can be processed directly by tools specific to each namespace with no transformation required.

Elimination of Nested xml Elements
One key driver behind this convention is that sequential, non-attributed, elements can be expressed as a single element whose name is a dotted accumulation of the names of the sequential elements, to the point that text content actually occurs. The dotted-name is simply easier to comprehend by humans as a result. When software reconstructs corresponding xml element structures from a dotted-name, software has freedom to create structures most appropriate to its own processing requirements.

Alignment with Object-oriented Methods
This convention depends upon a Dictionary that categorizes each of the parts of a dotted-name according to whether the name-part is a noun that represents a "real-world" entity (such as a person, place, or thing), an event that can occur to one of those entities, or a textual entry being made about the entity. There is a natural relationship between these names and the concept of "an object". The Dictionary formalizes this relationship by defining names of entities, events, and attributes as object classes. In a sense, then, this convention enforces the architecture that xml elements represent a serialized version of a software object. But it goes one step further.

This convention allows any particular object to be of multiple types. This convention allows any xml element to represent an object that is a "mix" of multiple types; mix-in classes are distinguished in the Dictionary as "qualified resource types". Due to these mix-in classes, a given xml element can dynamically specify what attributes are appropriate to it.

Separate Syntactic and Semantic Validation
One concern raised about the Named Value Notation is the presumed difficulties validating the arrangement of tokens in a name, and the values in the text content for the element. However to perform validation using today's tools, one needs merely to unpack the name, creating xml elements corresponding to each of the tokens in the name; that result is then submitted to, say, an xml Schema-based validation tool. But this issue actually begs a slightly larger question.

Business rules relevant to an xml datastream (as to any other format of datastream) are a function of an application for which the rules are being applied. The rules necessary for one application's processing of a given datastream are often different than those necessary for a different application. Given the current state of technology, all business rules cannot yet be parameterized as, say, an xml Schema. This means that the usual case is that most business rules of consequence are enforced in software written specifically for the datastream, that is, by the application itself once the datastream has been initially parsed. In the final analysis, most production-quality applications are written robustly enough that, implicitly, most of the rules that might be recorded in a DTD or xml Schema are re-applied by the software. The logical conclusion is that organizations who standardize a DTD or xml Schema are actually standardizing an interface to a specific application. While this outcome is appropriate for broad-based applications such as Internet browsers, it seems undesirable for all but a handful of domain-specific document types.

The Named Value Notation avoids this problem by not defining a DTD or Schema. Applications are free to establish on their own, internal DTDs and Schema that apply to the information they extract from the xhtml (or other xml) file. The Named Value Notation implements an architecture for document exchange in which source xhtml forms and xhtml documents are validated syntactically against the xhtml DTD, and are validated semantically at a minimum by visual inspection, or more mechanistically by scripts executed during data entry on an xhtml form. This architecture forces all semantic validation of named-values within the dc:names attribute to be performed by one's internal software or DTDs, thus unencumbering the standards process with a burden it need not carry in the first place.


2 Name Structure

This section defines the contents of tokens in a dotted-name, which fall into these general categories:

Data-entry Tokens
The name of the data that is the annotated string. These are names of attributing strings, numerics, and dates. Examples: Description.text, GivenName.text, Identifier.text, BuildingArea.sqft, Height.ft, AdministrativeExpense.usd, NotLaterThanDate.iso
Datatype Tokens
Indicates the language, units, format, and datatype of strings. Datatype tokens identifiy whether a string is a textual quantity, a numeric quantity, or a temporal quantity. Also identifies the "types" to assign to a resource; the bases for percentages and for numeric rates; and certain system values. These tokens are suffixes to noun tokens, data-entry tokens, and predicate tokens. Examples: Description.en, Land.Purchased.Cost.usd, Debt.type, Person.Height.2.pct.of.Person.Height.1.ft, Facility.OccupiedArea.sqft.per.1.Facility.BuildingArea.sqft, ReportingPeriod.year, Property.Purchased.iso, Contract.Duration.iso
Index Tokens
Numeric tokens occuring as a suffix to any part of the name for the annotated string. The index indicates a value's position within a sequence of similarly-named values. Examples: Person.Married.1.Date.text, Property.1.Owner.2.Address.1.City.Name.text, Location.Description.1.text
Namespace Tokens
Escapes this system with another naming system, allowing for direct specification of an xml datastream. Supported namespaces include Dublin Core, RDF, RDFS, DAML, xml, XMLNS, XLL, XSI, XSD, xhtml, and vCard. Examples: Document.dc.Title, Property.rdf.ID, Class.rdfs.comment.en, Class.daml.sameClassAs.rdf.ID, Description.xml.lang, Document.xll.href, Person.vc.fn, Document.Description.xsd.string, Document.html.style
Noun Tokens
Every dotted-name requires at least one noun that represents an Actor, Location, or Product, or a (legal) Property or (logical) Document. Successive nouns indicate possessive relationships. Examples: HeatingSystem.type, Fiduciary.Property.1.Worth.amount, Business.President.Appointed.Date.text
Predicate Tokens
Separates noun tokens with a named relationship. This token can be implied by two adjacent nouns, that is it can be determined by a dictionary look-up. Examples: Business.held.Property, Site.contains.Building, Person.memberOf.Group
Qualifier Tokens
Identifies events or topics relevant to a noun or data-entry value. Examples: Fiduciary.Managed.Property.1, Company.1.Purchased.Property, Person.1.Income.Estimated.Earned.usd
Time Tokens
Indicates the reporting period that applies to either a data-entry name, a noun, or a predicate. Time tokens appear prior to or following a data-entry name, prior to a predicate, and prior to a noun and its qualifiers. Examples: Document.ReportingPeriod.Duration.iso, RealEstate.Quarter.1.Cost.usd, Property.Current.Retired.Debt.Past.Retired.amount,

2.1 Datatype Tokens

Names specified in a dc:names attribute shall bear a suffix that indicates its datatype, formatting, units, or language. [Note: this rule can be escaped. See Namespace Tokens.] By convention, all suffixes are lower-case to distinguish them as name-terminators, for the benefit of both human readers and software applications.

String Value Suffixes

Names for all text strings that are not language-specific, or for which the language is unknown or unspecified, shall have a suffix of .text. For instance, most abbreviations are not subject to translations to other languages.
<foo dc:names='State.Abbreviation.text'>NY</foo>

// The following xml is one equivalent to the above name. 
<State>
   <Abbreviation> <text>NY</text> </Abbreviation>
</State> 
Names for all text strings that are of a certain language may have a suffix that is the lower-case equivalent of the values for the xml:lang attribute defined by the W3C (which are derived from ISO-639). For instance,
<foo dc:names='RealEstate.RelatedDocument.Title.en'>Site Survey</foo>
<foo dc:names='RealEstate.RelatedDocument.Title.sp'>Inspección del Sitio</foo>

// The following xml is one equivalent to the above name. 
<RealEstate>
   <RelatedDocument> 
      <Title> 
          <text xml:lang='en'>Site Survey</text> 
          <text xml:lang='sp'>Inspección del Sitio</text> 
      </Title>
   </RelatedDocument>
</RealEstate>
Names for all text strings that are to be re-constituted by an application shall have two suffixes. The first suffix shall follow the rules established for strings in general. The second suffix shall be a numeric that indicates its position within the reconstituted string. For instance, assume that the string "Site Survey" was split between two separate elements. Then,
<foo dc:names='RealEstate.RelatedDocument.Title.en.1'>Site </foo>
<foo dc:names='RealEstate.RelatedDocument.Title.en.2'>Survey </foo>

// The following xml is one equivalent to the above name. 
<RealEstate>
   <RelatedDocument> 
      <Title> <en>Site Survey</en> </Title>
   </RelatedDocument>
</RealEstate>

Numeric Value Suffixes

Names for numeric values whose string includes non-numeric characters (commas, letters, parentheses, etc.) shall have a suffix of .text.
<foo dc:names='Facility.OccupiedArea.text'>2,400 square feet</foo>

// The following xml is one equivalent to the above name. 
<Facility>
   <OccupiedArea> <text>2,400 square feet</text> </OccupiedArea>
</Facility> 
Names for numeric values that are integers shall have a suffix of .integer or its synonym, .value.
<foo dc:names='Region.Population.Census.integer'>480000</foo>

// The following xml is one equivalent to the above name. 
<Region>
   <Population> 
      <Census> <integer>480000</integer> </Census>
   </Population>
</Region> 
Names for integers that are a count of items shall have a suffix of .count. In the sample below, three different populations are identified, with the census information then provided for each.
<foo dc:names='Region.Population.count'>3</foo>
<foo dc:names='Region.Population.1.Census.integer'>120000</foo>
<foo dc:names='Region.Population.2.Census.integer'>240000</foo>
<foo dc:names='Region.Population.3.Census.integer'>120000</foo>

// The following xml is one equivalent to the above name. 
<Region>
   <actors'> 
   <Population id='Region.Population.1'> 
      <Census> <integer>120000</integer> </Census>
   </Population>
   <Population id='Region.Population.2'> 
      <Census> <integer>240000</integer> </Census>
   </Population>
   <Population id='Region.Population.3'> 
      <Census> <integer>120000</integer> </Census>
   </Population>
   </actors'> 
</Region> 
Names for numeric values that are decimals, for which the measurement unit is unknown, unspecified, or unspecifiable, shall have a suffix of .decimal or its synonym, .value. Decimal numbers without a decimal part are acceptable values.
<foo dc:names='Facility.OccupiedArea.decimal'>2400.00</foo>

// The following xml is one equivalent to the above name. 
<Facility>
   <OccupiedArea> <decimal>2400.00</decimal> </OccupiedArea>
</Facility> 
Names for numeric values that are percentages shall have a suffix of .percent or its abbreviation, .pct. Regardless of whether these are stated either as a decimal or an integer, the value '100.00' equals 100%. Following the "percent" suffix, and introduced by ".of" shall be the name for the value that the entry is a percentage of.
<foo dc:names='Facility.OccupiedArea.percent.of.BuildingArea'>60.0</foo>

// The following xml is one equivalent to the above name. 
<Facility>
   <OccupiedArea> <percent of='BuildingArea'>60.0</percent> </OccupiedArea>
</Facility> 
Names for numeric values that are of a specific unit shall have a suffix corresponding to a recognized abbreviation. For instance:
<foo dc:names='Facility.OccupiedArea.sqft'>12000</foo>
<foo dc:names='Room.Width.ft'>23</foo>
<foo dc:names='Site.Area.acre'>.55</foo>
<foo dc:names='Facility.DistanceFromTransportation.mi'>2.7</foo>

// The following xml is one equivalent to the above name. 
<Facility>
   <OccupiedArea> <quantity units='sqft'>12000</quantity> </OccupiedArea>
</Facility>
<Room>
   <Width> <quantity units='ft'>23</quantity> </Width>
</Room>
<Site>
   <Area> <quantity units='acre'>.55</quantity> </Area>
</Site>
<Facility>
   <DistanceFromTransportation> <quantity units='mi'>2.7</quantity> </DistanceFromTransportation>
</Facility> 

Financial Value Suffixes

Names for financial values whose string includes non-numeric characters (commas, currency symbols, parentheses, etc.) shall have a suffix of .text.
<foo dc:names='Transaction.ShippingAndHandlingCost.text'>$ 12.50</foo>

// The following xml is one equivalent to the above name. 
<Transaction>
   <ShippingAndHandlingCost> <text>$ 12.50</text> </ShippingAndHandlingCost>
</Transaction> 
Names for financial values whose currency is either unknown or unspecified shall have a suffix of .amount or its synonym, .value.
<foo dc:names='Transaction.ShippingAndHandlingCost.amount'>12.50</foo>

// The following xml is one equivalent to the above name. 
<Transaction>
   <ShippingAndHandlingCost> <amount>12.50</amount> </ShippingAndHandlingCost>
</Transaction> 
Names for financial values whose currency is known shall have a suffix that is the lower-case equivalent of the monetary codes defined by ISO-000.
<foo dc:names='Transaction.ShippingAndHandlingCost.usd'>12.50</foo>

// The following xml is one equivalent to the above name. 
<Transaction>
   <ShippingAndHandlingCost> <amount currency='usd'>12.50</amount> </ShippingAndHandlingCost>
</Transaction> 
Names for values that are rates identify the values, and units for those values, that are the denominators in the rate's ratios.
<foo dc:names='Facility.Rent.usd.per.1.Unit.per.2.month'>1250.00</foo>

// The following xml is one equivalent to the above name. In this encoding, the supporting DTD has an 
// element named 'usd', rather than an element named 'amount' which has an attribute named 'currency'.
<Facility>
   <Rent>
       <Rate per.1='Unit' per.2='Month' usd='1250.00'/> 
   </Rent>
</Facility>

//which is the same as 
<Facility>
   <Rent>
       <Rate>
          <per.1>Unit</per.1>
          <per.2>Month</per.2>
          <usd>1250.00</usd>
       </Rate> 
   </Rent>
</Facility> 

Date and Time Value Suffixes

Names for date and time values, whose string does not conform with one of the formats below, shall have a suffix of .text.
<foo dc:names='Facility.Opened.Date.text'>Wed 12/5/01</foo>

// The following xml is one equivalent to the above name. 
<Facility>
   <Opened> 
        <Date> <text>Wed 12/5/01</text> </Date> 
   </Opened>
</Facility> 
Names for specific date and time values conforming to ISO-8601 specifications shall have a suffix of .iso. The following represents 12:30pm on December 5, 2001, at the International Dateline.
<foo dc:names='Document.Received.Timestamp.iso'>2001-12-05T12:30Z</foo>

// The following xml is one equivalent to the above name. 
<Document>
   <Received> 
        <Timestamp> <iso>2001-12-05T12:30Z</iso> </Timestamp> 
   </Received>
</Document> 
Names for year, quarter, month, and day values shall have a suffix of .year, .month, or .day, whose value ranges are 1000+, 1-12, and 1-31 respectively. For time values, .hour, .minute, .second and .tz may be used. A shorthand that uses standard timezone abbreviations is also available (see the .cst suffix below, indicating the US Central Standard timezone). Similarly, .am and .pm suffixes are available.
<foo dc:names='Person.Born.Date.year'>1953</foo>
<foo dc:names='Person.Born.Date.month'>02</foo>
<foo dc:names='Person.Born.Date.day'>28</foo>
<foo dc:names='Person.Born.Time.hour'>22</foo>
<foo dc:names='Person.Born.Time.minute'>30</foo>
<foo dc:names='Person.Born.Time.second'>00</foo>
<foo dc:names='Person.Born.Time.tz'>CST</foo>
<foo dc:names='Person.Born.Duration.iso'>P12H30M</foo>
//  - or -
<foo dc:names='Person.Born.year'>1953</foo>
<foo dc:names='Person.Born.month'>02</foo>
<foo dc:names='Person.Born.day'>28</foo>
<foo dc:names='Person.Born.hour'>22</foo>
<foo dc:names='Person.Born.minute'>30</foo>
<foo dc:names='Person.Born.second'>00</foo>
<foo dc:names='Person.Born.tz'>CST</foo>
<foo dc:names='Person.Born.Duration.hour'>12</foo>
<foo dc:names='Person.Born.Duration.minute'>30</foo>
// - alternative time encodings
<foo dc:names='Person.Born.cst'>22:30:00</foo>
<foo dc:names='Person.Born.pm'>10:30:00</foo>

// The following xml is one equivalent to either set of the above names. 
<Person>
   <Born> 
        <Date> 
             <year>1953</year> 
             <month>02</month> 
             <day>28</day> 
        </Date> 
        <Time> 
             <hour>22</hour> 
             <minute>30</minute> 
             <second>00</second> 
             <tz>CST</tz> 
        </Time> 
        <Duration> 
             <hour>12</hour> 
             <minute>30</minute> 
        </Duration> 
   </Born>
</Person> 
The asOf suffix identifies the timestamp for the moment that the information was first known or recorded, or was last amended or validated by the publisher. For instance, an <Address> whose asOf value is "1998-11-01" means the address was known, recorded, revised, or validated on November 1st, 1998 by the publisher.
<foo dc:names='Document.asOf'>2001-12-05T12:30Z</foo>
<foo dc:names='Company.Address.asOf'>1998-11-01</foo>

// The following xml is one equivalent to the above name. 
<Document asOf='2001-12-05T12:30Z'>
   <Company>
        <Address asOf='1998-11-01'/>
   </Company>
</Document> 
The content of "asOf" shall conform to the ISO date/time format and, should a date only be provided, then midnight is to be the assumed moment during the day. Should a month only be provided, then midnight on the first day of the month is to be assumed. Should a year only be provided, then midnight on the first day of the year is to be assumed. It is an error should a time only be provided. If an hour only is provided, then the zeroth minute of the hour is to be assumed.

For any specific element, if this attribute is not provided a value, then its value is to be inherited from a parent element in the datastream. If no parent element provides a value for this attribute, then it is to be assigned a value of the moment that the datastream was provided by its publisher. This algorithm allows a publisher to (a) identify the currency of all child elements with a single attribute on their parent element (b) identify those child elements whose currency is an exception to the currency of a parent element. Given that information recorded asOf a certain-date is equally recorded asOf every date since that certain-date, it is logically consistent and correct to default the value of this attribute to the retrieval date/time for the datastream.

It is an error should a parent element have an asOf timestamp that is earlier in time than an asOf timestamp on any one of its child elements.

System Value Suffixes

Names for strings that are the units to be associated with a value shall have a suffix of .units. These names allow units to be selectable by a user interface and shall be any one of the suffixes defined in this section, with the exception of a numeric concatenation suffix.
<foo dc:names='Document.ReportingPeriod.units'>year</foo>

// The following xml is one equivalent to the above names. 
<Document>
   <ReportingPeriod> 
        <units>year</units> 
   </ReportingPeriod>
</Document> 
Names for strings that are a type defined in the dictionary shall have a suffix of .type. This is used to assign a type to the item, and shall substitute for all uses of boolean values elsewhere in this system. In other words, boolean values are established as individual terms in the dictionary, so that properties may be associated with them.
<foo dc:names='Fiduciary.Fund.type'>ClosedEndFund</foo>

// The following xml is one equivalent to the above names. 
<Fiduciary>
   <Fund> <type>ClosedEndFund</type> </Fund>
</Fiduciary> 
Names for strings that are dotted-names, can be expressed as values and shall have a suffix of .name. These names effectively function is idref values. In the sample below, the fund with which a specific real estate property is associated is identified as "Fiduciary.Fund.3", defined elsewhere in the datastream.
<foo dc:names='Fiduciary.RealEstate.Fund.name'>Fiduciary.Fund.3</foo>

// The following xml is one equivalent to the above names. 
<Fiduciary>
   <RealEstate>
       <Fund> <name>Fiduciary.Fund.3</name> </Fund>
   </RealEstate>
</Fiduciary> 

2.2 Data-entry Tokens

Every name shall contain at least one data-entry token, which is located to the left of the suffix token described above. For example
<foo dc:names='Document.RealEstate.PotentialGrossIncome.usd'>1000.00</foo>

// The following xml is one equivalent to the above name. 
<Document>
   <RealEstate>
     <PotentialGrossIncome> <usd>1000.00</usd> </PotentialGrossIncome>
   </RealEstate>
</Document> 
An enumeration of the data-entry tokens are located in the Data Consortium Dictionary as subclasses of the Entry class. Its immediate subclasses are the Memo, Quantity, and Time classes (in addition to the QualifiedEntry class); these classes correspond to the names for text values, numeric values, and date/time values. In other words, all attributes that resolve to a string, not to an object reference, are defined as a subclass of the Entry class.
In Table 1, Entry Class Taxonomy, a selected account of the Data Consortium's hierarchy of classes/subclasses is provided. The taxonomy contains not only typical items such as Name and Description, but also ones that are "qualified values". For instance, subclasses of the Measurement class includes Large, Small, and so on. In order to associate one of these descriptors with (for instance) a dining-room in a facility, then
<foo dc:names='Facility.DiningRoom.Area.type'>Small</foo>

// The following xml is one equivalent to the above names. 
<Facility>
   <DiningRoom> 
        <Area> <type>Small</type> </Area>
   </DiningRoom>
</Facility> 

Table 1 Entry Class Taxonomy (Selected)

Source: http://search.dataconsortium.org

Entry
    QualifiedEntry
        MethodQualifiedEntry
        TimeQualifiedEntry
        UseQualifiedEntry
    Memo
        Block 
        Description
        Feature
            Access
            Color
            Environment
            Orientation
            PersonalFeature
            Right
            Safety
            Shape
            Style
        Identifier
        Method
            MeasurementMethod
    Quantity
        QualifiedQuantity
        Amount
            QualifiedAmount
            AccountingEntry
                 QualifiedAccountingEntry
                 Asset
                 Equity
                 Expense
                 Income
                 Liability
           TransactionEntry
                 Adjustment
                 Charge
                 Cost
                 Revenue
           Value
                Interest
                Price
                Profit
                Rent
                Worth
        Count
        Index
        Measurement
        Percentage
        Probability
        Range
    Time
        Date
            QualifiedDate
            EndDate
            EventDate
            StartDate
        Duration
        Period
        TimeSeries
Root class for all textual attributes
Root class for general qualifiers for entries
EstimatedEntry CalculatedEntry BudgetedEntry CorrectedEntry ...
PreviousEntry CurrentEntry FutureEffectiveEntry LatestEntry ...
AuditorEntry 
Root class for all string attributes
... Footer Header ImageBlock Line List Page Section Sound TextBlock ...
Name Note Rank and Type

HandicappedAccess RestrictedAccess Sensitivity etc
Approximately 160 generic colors are subclasses
Arid Calm Clean Clear Cold Cool Damp ...
Atop Backwards Corner East Exterior ...
Ethnicity EyeColor Gender Hair HairColor HairLength etc
... LendeeRight LenderRight LesseeRight LessorRight OwnerRight ...
Dangerous Fireproof Fireresistant Potable Safe ...
Bayshape Bevel Bullnose Circular Elliptical Concave ...
ConstructionStyle DesignStyle ...
Address Combination InstitutionID LicenseNumber ...
Class for names of methods and processes
EnglishMeasurement MetricMeasurement
Root class for all numeric attributes

Root class for all financial amounts
AuthorizedAmount BudgetedAmount CommittedAmount ObligatedAmount ...
Root class for entries that are made to financial accounts
AdjustingEntry ClosingEntry ExtraordinaryEntry OpeningEntry ...
AmountReceivable BeforetaxEquityReversion BookValue ImpliedEquityMarketCap ...
LeveragedEquity PlottageValue SweatEquity UnleveragedEquity ...
BusinessExpense FacilityExpense GeneralAndAdministrativeExpense LaborExpense ...
BusinessIncome OperatingIncome QualifiedIncome ServiceIncome ...
AmountPayable DebtFinancing DebtService OutstandingDebt TotalLiability ...
Root class for entries that are involved with a transaction
Credit Debit Discount etc
Compensation (BonusPay ...) Fee (AdministrativeFee ConstructionFee FinancialFee ...) ...
QualifiedCost ProductCost SalesCost TaxCost ...
QualifiedRevenue ProductRevenue SalesRevenue TaxRevenue ...
Root class for entries that express a simple financial value
AccruedInterest CompoundInterest CreditCardInterest MortgageInterest SimpleInterest etc
InsurancePremium QualifiedPrice UnitPrice

BuildingShellRent DoubleNetRent FlatRent GroundRent IndexedRent StepRent ...
MarketValue PresentValue TaxValue ...
 ...
ConsumerPriceIndex CostOfLivingIndex HousingAffordabiityIndex ParkingIndex ...
Area Capacity Density Distance Frequency Gradient Speed Temperature  ...
AmortizationRate AssessmentRatio AverageAskingLeaseRate CaptureRate ...
CreditScore MarketRentalRisk RenewalProbability ...

Root class for all time-related attributes

EarliestDate LatestDate NotLaterThanDate
ClosingDate Deadline DelinquencyDate YearBuilt ...
AnniversaryDate AppraisalDate AsofDate CommitmentDate DueDate ...
CreationDate LeaseCommencementDate OccupancyDate
Age AgeOfFacilities AverageDowntime EconomicAge LegalAge LifeOfLoan ...
AbsorptionPeriod ... AmortizationPeriod BalloonPeriod BasePeriod ...

2.3 Noun Tokens

Nouns, that is, names of resource-types, are inventoried for the commercial real estate domain in the Data Consortium Dictionary as subclasses of the DCNResource class. Resource-types are either for a "principal" resource or a "dependent resource". Principal resources are ones that have attributes represented by dependent resources. A principal resource is meaningful on its own merits, while a dependent resource only meaningfully can be an attribute of a principal resource, or of another dependent resource.
In the Dictionary, principal resources are one of five classes: Actor, Document, Location, Product, and Property. In a sense, these correspond to tangible "persons, places, or things", and to intangible concepts of "document" and of "legal property", which are as substantial as tangible resources. The Dictionary also defines four dependent resource types (those that name characteristics of principal resources): Entry, Event, Service, and Topic classes (described elsewhere).
Actor
The Actor class taxonomy is designed according to Dublin Core designations, and contains subclasses Company , Group, Institution, Organization, and Person. Company is composed of the kinds of establishments identified by the North American Industrical Classification System (NAICS), and is composed of entities who hold business licenses to operate. Group contains associations composed of companies, other groups, institutions, organizations, and persons. Institution contains governments, corporations, trusts, and marriages, that is, those entities requiring a charter to exist. Organization contains registered non-profit entities. Person contains two subclasses, Male and Female. See Table 2.
Document
The Document class contains the names of types of documents that are or can be the subject of document interchange in the commercial real estate domain. These are organized according to NAICS categories. See Table 3.
Location
This class has subclasses for Boundary, Facility, Structure, Space, and Surface. Buildings, floors, and rooms are subclasses of Structure, while Surface is divided between Land, Water, and StructuralSurface. District, Landform, Region, Site, and Zone are subclasses of Land. Facilities are organized according to NAICS. See Table 4.
Product
A Product is an economic good, such as a product of agriculture or mining, or an article of commerce. It is substantially a product to which a Universal Product Code, or a SKU, can be assigned. See Table 5.
Property
The rights or interests a person has in the thing he or she owns; not, in the technical sense, the thing itself. These rights are called the 'Bundle of Rights', including the right to possess, to use, to encumber, to transfer, and to exclude. This class has subclasses corresponding to a classic legal taxonomy, PersonalProperty and RealProperty, to which PropertyInterest has been added. RealProperty decomposes to Fixture and RealEstate, while RealEstate is organized using classifications provided by the Real Estate Information Standards. PersonalProperty contains TangibleProperty and IntangibleProperty. IntangibleProperty contains CashInstrument, Goodwill, LegalInstrument, and IntellectualProperty. LegalInstrument contains Contract, DebtInstrument, Deed, DepositInstrument, Easement, Insurance, Lien, and RestrictiveCovenant. See Table 6.
Every Named Value Name requires at least one name of a principal resource-type. In the samples below, a "PropertyManager" is a sub-type of "Person" (via the QualifiedPerson, PersonalRole, and Role classes); a "QuarterlyREIFReport" is a sub-type of "Document" (via the Report and RealEstateDocument classes); a "HighRiseBuilding" is a sub-type of "Location" (via the QualifiedBuilding, Building, and Structure classes); a "HeatingSystem" is a sub-type of "Product" (via the BuildingProduct class);and a "LowRiseOfficeProperty " is a sub-type of "Property" (via the REISOfficeProperty, REISProperty, and RealEstate classes).
<foo dc:names='PropertyManager.LastName.text'>Lincoln</foo>
<foo dc:names='QuarterlyREIFReport.ReportingPeriod.EndDate.iso'>2002-03-31</foo>
<foo dc:names='HighRiseBuilding.Height.ft'>1235</foo>
<foo dc:names='HeatingSystem.type'>ForcedAirHeatingSystem</foo>
<foo dc:names='LowRiseOfficeProperty .Developed.Date.year'>1967</foo>

// The following xml is one equivalent to the above names. 

<PropertyManager>
   <LastName> <text>Lincoln</text> <LastName>
</PropertyManager>
<QuarterlyREIFReport>
   <ReportingPeriod> 
      <EndDate> <iso>2002-03-31</iso> <EndDate>
  </ReportingPeriod>
</QuarterlyREIFReport>
<HighRiseBuilding>
   <Height> <ft>1235</ft> <Height>
</HighRiseBuilding>
<HeatingSystem>
   <type>1235</type>
</HeatingSystem>
<LowRiseOfficeProperty>
   <Developed> 
      <Date> <year>1967</year> <Date>
  </Developed>
</LowRiseOfficeProperty> 
In order to name nodes in a logical data model, principal resources can be consecutively specified. In the example below, it can be seen that the data model establishes that rooms are within units; units are on floors; floors are part of a building; buildings are located on a site; and a site is part of a real estate property.
<foo dc:names='RealEstate.Name.text'>Sears Block</foo>
<foo dc:names='RealEstate.Site.Name.text'>Sears Tower Complex</foo>
<foo dc:names='RealEstate.Site.Building.Name.text'>Sears Tower</foo>
<foo dc:names='RealEstate.Site.Building.Floor.Name.text'>12th Floor</foo>
<foo dc:names='RealEstate.Site.Building.Floor.Unit.Name.text'>Suite 1232</foo>
<foo dc:names='RealEstate.Site.Building.Floor.Unit.Room.Name.text'>Reception</foo>

// The following xml is one equivalent to the above names. 

<RealEstate>
   <Name> <text>Sears Block</text> </Name>
   <Site>
      <Name> <text>Sears Tower Complex</text> </Name>
      <Building>
         <Name> <text>Sears Tower</text> </Name>
         <Floor>
            <Name> <text>12th Floor</text> </Name>
            <Unit>
               <Name> <text>Suite 1232</text> </Name>
               <Room>
                  <Name> <text>Reception</text> </Name>
               </Room>
            </Unit>
         </Floor>
      </Building>
   </Site>
</RealEstate> 
The dictionary identifies the default relationship that exists between pairs of resource-types. However, more than the default relationship can exist. For instance, a Person by default "holds" property, however other relationships between a Person and Property can be indicated by using predicate tokens.

2.4 Index Tokens

Often, a name needs to be suffixed with a numeric index in order to distinguish it from other, same-named nodes within a single branch of one's data model. For instance, a datastream that identifies all purchase transactions for a given property would need to use a numeric index to correctly place attributes associated with each of the transactions. In the sample below, the seller(s) for each purchase is provided; without the numeric index as a suffix on the "Purchased" event, one couldn't determine the seller associated with each purchase.
<foo dc:names='RealEstate.Purchased.1.Seller.Name.text'>George Washington</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.1.Name.text'>John Adams</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.2.Name.text'>Abigail Adams</foo>

// The following xml is one equivalent to the above names. 
// Note that the id attribute contains the named-value name, functioning like an XPATH expression.

<RealEstate>
   <Purchased id='RealEstate.Purchased.1'> 
      <Seller> 
         <Name> <text>George Washington</text> </Name>
      </Seller> 
   </Purchased>
   <Purchased id='RealEstate.Purchased.2'> 
      <Seller id='RealEstate.Purchased.2.Seller.1'> 
         <Name> <text>John Adams</text> </Name>
      </Seller> 
      <Seller id='RealEstate.Purchased.2.Seller.2'> 
         <Name> <text>Abigail Adams</text> </Name>
      </Seller> 
   </Purchased>
</RealEstate>
Index tokens are 1-based, that is, the zero'th index value is reserved for use by application software. Index tokens should be consecutively assigned from "1". Note that the suffix, ".count", can be meaningfully specified by a datastream, as in
<foo dc:names='RealEstate.Purchased.count'>2</foo>
<foo dc:names='RealEstate.Purchased.1.Seller.Name.text'>George Washington</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.1.Name.text'>John Adams</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.2.Name.text'>Abigail Adams</foo>

// The following xml is one equivalent to the above names. 

<RealEstate>
   <events name='Purchased' count='2'>
   <Purchased id='RealEstate.Purchased.1'> 
      <Seller> 
         <Name> <text>George Washington</text> </Name>
      </Seller> 
   </Purchased>
   <Purchased id='RealEstate.Purchased.2'> 
      <Seller id='RealEstate.Purchased.2.Seller.1'> 
         <Name> <text>John Adams</text> </Name>
      </Seller> 
      <Seller id='RealEstate.Purchased.2.Seller.2'> 
         <Name> <text>Abigail Adams</text> </Name>
      </Seller> 
   </Purchased>
   </events>
</RealEstate>

2.5 Predicate Tokens

2.6 Qualifier Tokens

Optional qualifier tokens apply to all nouns defined in the dictionary, that is, to names of principal and dependent resource-types, event names, and data-entry names. Two types of qualifiers are defined: events and topics For data-entry names, the qualifiers follow the name, while for all other nouns, qualifiers precede the name.

Data Entry Qualifier Tokens
Data-entry qualifier tokens appear in a dotted-name to the left of the suffix for a data-entry name. Qualifiers are events which apply to the specific data-entry name. As many qualifiers as apply to the data-entry name may be specified, and their ordering is unimportant.
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.usd'>12345</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Revised.Estimated.usd.per.1.BuildingArea.sqft'>12.35</foo>

// The following xml is one equivalent to the above names. 
// Typing information and events have been inserted based upon the qualifiers in the name.

<RealEstate>
   <AdministrativeExpense>
      <type>Estimate</type>
      <usd>12345</usd>
      <Estimated/>
   </AdministrativeExpense>
   <AdministrativeExpense>
      <type>Revision</type>
      <Revised/>
      <type>Estimate</type>
      <Estimated/>
      <Rate per.1='BuildingArea.sqft'> <usd>12.35</usd> <Rate>
   </AdministrativeExpense>
</RealEstate> 
The table below shows the event-qualifiers that can be specified for numeric quantities. It is arranged as a taxonomy, meaning that a given Entry-type inherits event-qualifiers applicable to its superclasses. For instance, the set of event-qualifiers that may be specified for Income includes: Assumed, Managed, Planned, Recorded, Revised Contracted, Offered, Proposed, Adjusted, Annualized, Averaged, Calculated, Estimated, Forecasted, Maximized, Minimized, Normalized, Projected, Prorated, Rounded, Converted, Netted, Totalled, Entered, Reversed, Earned, Owed, and Paid.
Event/Quantity Taxonomy Events that may be used as a qualifier for each type.

Resource
  Entry
    Quantity 

        Amount
            AccountingEntry
                 Asset
                 Equity
                 Expense
                 Income
                 Liability
           TransactionEntry
                 Adjustment
                 Charge
                 Cost
                 Revenue
           Value
                Fee
                Interest
                Price
                Rent
                Worth

Archived, Assumed, Managed, Planned, Recorded, Revised
Contracted, Offered, Proposed
Adjusted, Annualized, Averaged, Calculated, Estimated, Extrapolated, Forecasted, 
Interpolated, Maximized, Minimized, Normalized, Projected, Prorated, Rounded
Converted, Netted, Totalled
Credited, Debited, Entered, Reversed



Earned, Owed, Paid
Incurred, Retired
Budgeted
Applied
Invoiced, Rescinded
Appropriated, Committed, Obligated, Expended, Disbursed
Tendered
Qualifiers can have attributes. For instance, to provide a description and the date of an estimation, the result would be
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.usd.per.1.BuildingArea.sqft'>12.35</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.Description.text'>Assumptions are from ...</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.Date.iso'>2001-01-31</foo>

// For a contrast, here is a description of the expense itself...
<foo dc:names='RealEstate.AdministrativeExpense.Description.text'>Includes these expenses ...</foo>

// The following xml is one equivalent to the above names. 

<RealEstate>
   <AdministrativeExpense>
      <type>Estimate</type>
      <Rate per.1='BuildingArea.sqft'> <usd>12.35</usd> </Rate> 
      <Estimated>
         <Description> <text>Assumptions are from ...</text> </Description>
         <Date> <iso>2002-01-31</iso> </Date>
      </Estimated>
      <Description> <text>Includes these expenses ...</text> </Description>
   </AdministrativeExpense>
</RealEstate> 

Noun Qualifier Tokens
Nouns are qualified in order to identify one or more common characteristics that are, in effect, selectors of instances having the common characteristics. Noun qualifier tokens, placed prior to a noun, may only be events that apply to the noun. For instance, an investment manager reporting on specific real estate properties that are "active" in a managed portfolio, qualifies the individual properties as "Managed" properties. Multiple qualifiers are and'ed as in the below sample of a managed property that was acquired by the manager during the period.
<foo dc:names='Fiduciary.Managed.RealEstate.1.TaxAssessment.usd'>1250000.00</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.AssessmentTax.usd'>7500.00</foo>
<foo dc:names='Fiduciary.Managed.Distressed.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>

// The following xml is one equivalent to the above names. 

<Fiduciary>
   <RealEstate id='Fiduciary.Managed.RealEstate.1'>
      <TaxAssessment> <usd>1250000.00</usd> </TaxAssessment>
      <AssessmentTax> <usd>7500.00</usd> </AssessmentTax>
      <Managed/>
   </RealEstate>
   <RealEstate id='Fiduciary.Managed.Distressed.RealEstate.1'>
      <TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
      <Managed/>
      <Distressed/>
   </RealEstate>
</Fiduciary> 
In the sample above, qualifiers are implied to be attributes of the resource, in order that it be selected. This fact must be observed when the qualifiers are to have attributes themselves.
<foo dc:names='Fiduciary.Managed.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.Managed.Started.Date.year'>1987</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.Managed.Stopped.Date.year'>2002</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.Managed.Manager.TelephoneNumber.text'>202-555-1212</foo>

// The following xml is one equivalent to the above names. 

<Fiduciary>
   <RealEstate id='Fiduciary.Managed.RealEstate.1'>
      <TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
      <Managed>
         <Started> <Date> <year>1987</year> </Date> </Stopped> 
         <Stopped> <Date> <year>2002</year> </Date> </Stopped> 
         <Manager> 
            <TelephoneNumber> <text>202-555-1212</text> </TelephoneNumber>
         </Manager> 
      </Managed>
   </RealEstate>
</Fiduciary> 
This implements a consistent model because the alternative approach is to first associate a property with the fiduciary, and then reference it as a qualified resource.
<foo dc:names='Fiduciary.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
<foo dc:names='Fiduciary.RealEstate.1.Managed.Started.Date.year'>1987</foo>
<foo dc:names='Fiduciary.RealEstate.1.Managed.Stopped.Date.year'>2002</foo>
<foo dc:names='Fiduciary.RealEstate.1.Managed.Manager.TelephoneNumber.text'>202-555-1212</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.name'>Fiduciary.RealEstate.1</foo>

// The following xml is one equivalent to the above names. 

<Fiduciary>
   <RealEstate id='Fiduciary.RealEstate.1'>
      <TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
      <Managed>
         <Started> <Date> <year>1987</year> </Date> </Stopped> 
         <Stopped> <Date> <year>2002</year> </Date> </Stopped> 
         <Manager> 
            <TelephoneNumber> <text>202-555-1212</text> </TelephoneNumber>
         </Manager> 
      </Managed>
   </RealEstate>
   <RealEstate id='Fiduciary.Managed.RealEstate.1' idref='Fiduciary.RealEstate.1'/>
</Fiduciary> 
Names of topics may also be noun qualifiers. In the Dictionary, all plural nouns — all lists — are names of topics. Topics are containers for information about a resource, meaning that all its attributes are equally attributes of the resource to which the topic applies. For instance, the Data Consortium's DTD, Version 1.50 specifies that all elements representing actors are to be located within an <Actors> element, which is within the <DCN> element. "Actors" is a topic (as are Documents, Entries, Events, Locations, Products, Properties, Services, and Topics). If one desired, a topic called "ActiveProperties" could be created, giving the following coding.
<foo dc:names='Actors.Person.1.TelephoneNumber.text''>202-555-1212</foo>

<foo dc:names='Fiduciary.ActiveProperties.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
<foo dc:names='Fiduciary.ActiveProperties.RealEstate.1.Manager.name>Actors.Person.1</foo>

// The following xml is one equivalent to the above names. 

<Actors>
   <Person id='Actors.Person.1'>
      <TelephoneNumber> <text>202-555-1212</text> </TelephoneNumber>
   </Person >
</Actors>

<Fiduciary>
   <ActiveProperties>
      <RealEstate id='Fiduciary.ActiveProperties.RealEstate.1'>
         <TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
         <Manager idref='Actors.Person.1'/> 
      </RealEstate>
   </ActiveProperties>
</Fiduciary> 

2.7 Time Tokens

To associate data-entry values with a specific reporting period, a time expression is inserted as a prefix to the predicate/entry names. In the example below, five quarters of data are provided. First, a specific quarter is identified, and then information relating to the quarter is provided. Then, a year is identified, and data for each of its four quarters are provided.
<foo dc:names='RealEstate.Quarter.1.EndDate.iso'>2001-03-31</foo>
<foo dc:names='RealEstate.Quarter.1.AdministrativeExpense.usd.per.1.BuildingArea.sqft'>12.35</foo>
<foo dc:names='RealEstate.Year.1.year'>2002</foo>
<foo dc:names='RealEstate.Year.1.Quarter.1.AdministrativeExpense.Estimated.usd'>12345.00</foo>
<foo dc:names='RealEstate.Year.1.Quarter.2.AdministrativeExpense.Estimated.usd'>23451.00</foo>
<foo dc:names='RealEstate.Year.1.Quarter.3.AdministrativeExpense.Estimated.usd'>34512.00</foo>
<foo dc:names='RealEstate.Year.1.Quarter.4.AdministrativeExpense.Estimated.usd'>45123.00</foo>

// The following xml is one equivalent to the above names. 

<RealEstate>
   <Quarter id='RealEstate.Quarter.1>
       <EndDate> <iso>2001-03-31</iso> </EndDate>
       <AdministrativeExpense>
             <type>Estimate</type>
             <Estimated/>
             <Rate per.1='BuildingArea.sqft'> <usd>12.35</usd> </Rate> 
       </AdministrativeExpense>
   </Quarter>
   <Year id='RealEstate.Year.1'>
       <year>2002</year>
       <Quarter id='RealEstate.Year.1.Quarter.1'>
           <AdministrativeExpense>
             <type>Estimate</type>
             <usd>12345.00</usd>
             <Estimated/>
          </AdministrativeExpense>
       </Quarter>
       <Quarter id='RealEstate.Year.1.Quarter.2'>
           <AdministrativeExpense>
             <type>Estimate</type>
             <usd>23451.00</usd>
             <Estimated/>
          </AdministrativeExpense>
       </Quarter>
       <Quarter id='RealEstate.Year.1.Quarter.3'>
           <AdministrativeExpense>
             <type>Estimate</type>
             <usd>34512.00</usd>
             <Estimated/>
          </AdministrativeExpense>
       </Quarter>
       <Quarter id='RealEstate.Year.1.Quarter.4'>
           <AdministrativeExpense>
             <type>Estimate</type>
             <usd>45123.00</usd>
             <Estimated/>
          </AdministrativeExpense>
       </Quarter>
   </Year>
</RealEstate> 
Due to the amount of repeated information, the sample above can be cumbersome as more time periods are added, or as more types of expenses are reported. To address this, a resource's "ReportingPeriod" can anchor time-expressions — if a resource does not define its own reporting period, then it defaults to the reporting period(s) defined for its parent elements, to the level of the document.
<foo dc:names='RealEstate.ReportingPeriod.1.BeginDate.iso'>2001-01-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.2.BeginDate.iso'>2002-01-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.3.BeginDate.iso'>2002-04-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.4.BeginDate.iso'>2002-07-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.5.BeginDate.iso'>2002-10-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.1.EndDate.iso'>2001-03-31</foo>
<foo dc:names='RealEstate.ReportingPeriod.2.EndDate.iso'>2002-03-31</foo>
<foo dc:names='RealEstate.ReportingPeriod.3.EndDate.iso'>2002-06-30</foo>
<foo dc:names='RealEstate.ReportingPeriod.4.EndDate.iso'>2002-09-31</foo>
<foo dc:names='RealEstate.ReportingPeriod.5.EndDate.iso'>2002-12-31</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.1.usd.per.1.BuildingArea.sqft'>12.35</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.2.usd'>12345.00</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.3.usd'>23451.00</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.4.usd'>34512.00</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.5.usd'>45123.00</foo>

// The following xml is one equivalent to the above names. 

<RealEstate>
   <ReportingPeriod id='ReportingPeriod.1'>
      <BeginDate> <iso>2001-01-01</iso> </BeginDate>
      <EndDate> <iso>2001-03-31</iso> </EndDate>
   </ReportingPeriod>
   <ReportingPeriod id='ReportingPeriod.2'>
      <BeginDate> <iso>2002-01-01</iso> </BeginDate>
      <EndDate> <iso>2002-03-31</iso> </EndDate>
   </ReportingPeriod>
   <ReportingPeriod id='ReportingPeriod.3'>
      <BeginDate> <iso>2002-04-01</iso> </BeginDate>
      <EndDate> <iso>2002-06-30</iso> </EndDate>
   </ReportingPeriod>
   <ReportingPeriod id='ReportingPeriod.4'>
      <BeginDate> <iso>2002-07-01</iso> </BeginDate>
      <EndDate> <iso>2002-09-31</iso> </EndDate>
   </ReportingPeriod>
   <ReportingPeriod id='ReportingPeriod.5'>
      <BeginDate> <iso>2002-10-01</iso> </BeginDate>
      <EndDate> <iso>2002-12-31</iso> </EndDate>
   </ReportingPeriod>
   <AdministrativeExpense>
      <type>Estimate</type>
      <Estimated/>
      <Rate per.1='BuildingArea.sqft'> <usd time='ReportingPeriod.1'>12.35</usd> </Rate>
      <usd time='ReportingPeriod.2'>12345.00</usd>
      <usd time='ReportingPeriod.3'>23451.00</usd> 
      <usd time='ReportingPeriod.4'>34512.00</usd> 
      <usd time='ReportingPeriod.5'>45123.00</usd> 
   </AdministrativeExpense>
</RealEstate>

2.8 Namespace Tokens

An escaping notation is provided by reserved tokens that signal specific xml namespaces. This feature provides access to xml elements and attributes defined by the namespace. The xml namespaces supported by this feature include

Resource Description Framework (RDF)
The rdf token provides information for an RDF element or attribute. The first example below assigns an RDF identifier (a URI) to a document.
<foo dc:names='Document.rdf.ID'>http://www.dot.com/Valuation.2001-12-31.html</foo>
<foo dc:names='Document.rdf.type'>dc:ValuationReport</foo> <!–– assign type from Dictionary to instance––>
<foo dc:names='Document.rdf.Description'/> <!–– create resource as child of instance––>
<foo dc:names='Document.rdf.RDF'/> <!–– start RDF datastream as child of instance.––> 
These statements can be coded directly, using an rdf:names attribute on the foo element, with the provisio that they must appear on an element that is within scope of a parent resource element. See
xhtml Markup Rules for more information about setting scope.
<foo rdf:names='ID'>http://www.dot.com/Valuation.2001-12-31.html</foo>
<foo rdf:names='type'>dc:ValuationReport</foo> <!–– assign type from Dictionary to instance––>
<foo rdf:names='Description'> <!–– create resource as child of instance––>
<foo rdf:names='RDF'> <!–– start RDF datastream as child of instance.––> 
RDF Schema (RDFS)
The rdfs token provides information for an RDFS element or attribute. All names referenced in a datastream are defined as RDF Schema classes. Below, a Property is defined whose name is the dotted-notation — this is the basis for script language processing.
<foo dc:names='Resource.rdfs.Class.rdf.ID'>ArgusValuationReport</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.subClassOf'>dc:ValuationReport</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.label'>My Argus Valuation Document</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.comment'>Subclasses dc:ValuationReport class.</foo>

<foo dc:names='Resource.rdfs.Class.rdf.ID'>ArgusID</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.subClassOf'>dc:Identifier</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.label'>Argus Identifier</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.comment'>Argus identifier from page 1 of output.</foo>

<foo dc:names='Resource.rdf.Property.rdfs.subPropertyOf'></foo>
<foo dc:names='Resource.rdf.Property.rdfs.label'>ArgusValuationReport.ArgusID</foo>
<foo dc:names='Resource.rdf.Property.rdfs.comment'>Associate A new property.</foo>
<foo dc:names='Resource.rdf.Property.rdfs.range>ArgusID</foo>
<foo dc:names='Resource.rdf.Property.rdfs.domain>ArgusValuationReport</foo> 
Class definition statements can be coded directly, using an rdfs:names attribute on the foo element, with the provisio that they must appear within the scope of a resource. For instance
<foo rdfs:names='Class.rdf.ID'>ArgusID</foo>
<foo rdfs:names='Class.rdfs.subClassOf'>dc:Identifier</foo>
<foo rdfs:names='Class.rdfs.label'>Argus Identifier</foo>
<foo rdfs:names='Class.rdfs.comment'>Argus' identifier from page 1 of output.</foo> 
Within the scope of a rdfs:Class, relevant terms can be coded without qualification.
<foo rdfs:names='subClassOf'>dc:ValuationReport</foo>
<foo rdfs:names='label'>Argus Identifier</foo>
<foo rdfs:names='comment'>Argus identifier from page 1 of output.</foo> 
Similarly, within the scope of a rdf:Property, relevant terms can be coded without qualification.
<foo rdfs:names='subPropertyOf'></foo>
<foo rdfs:names='label'>Argus Identifier</foo>
<foo rdfs:names='comment'>Argus identifier from page 1 of output.</foo>
<foo rdfs:names='range'>ArgusID</foo>
<foo rdfs:names='domain'>ArgusValuationReport</foo> 
Extensible Markup Language (xml)
The xml token provides information for several attributes defined by the W3C.
<foo dc:names='Resource.xml.id'>put-single-token-here</foo>
<foo dc:names='Resource.xml.lang'>en</foo>
<foo dc:names='Resource.xml.base'>put-base-uri-here.</foo> 
xml Namespace (XMLNS)
The xmlns token is used to identify a namespace which can be referenced by this namespace-escaping mechanism.
<foo dc:names='Resource.xmlns.xxx'>put-namespace-uri-here.</foo> 
DARPA Agent Markup Language (DAML)
The daml token provides direct access to elements and attributes defined by the DAML protocol.
<foo dc:names='Resource.Class.daml.sameClassAs'>dc:SomeClassName</foo> 
xml Schema Instance (XSI)
The xsi token provides information for one attribute defined by the W3C in the XSI namespace.
<foo dc:names='Resource.xsi.type'>Document</foo> 
Dublin Core (DC)
The dc token provides information for any of the Dublin Core resource-cataloging elements, as follows
<foo dc:names='Document.dc.Title'>Portfolio Valuations, as of Dec 31, 2001</foo>
<foo dc:names='Document.dc.Creator'>Commercial Real Estate Management, Inc.</foo>
<foo dc:names='Document.dc.Contributor'>US Dept of Commerce</foo>
<foo dc:names='Document.dc.Coverage'>Active Properties in Portfolio, 12-31-2001</foo>
<foo dc:names='Document.dc.Date'>2001-12-31</foo>
<foo dc:names='Document.dc.Description'>This valuation uses 12/01/01 assumptions.</foo>
<foo dc:names='Document.dc.Format'>text/xml</foo>
<foo dc:names='Document.dc.Identifier'>http://www.dot.com/Valuation.2001-12-31.html</foo>
<foo dc:names='Document.dc.Language'>EN</foo>
<foo dc:names='Document.dc.Publisher'>Internet Publishing Company</foo>
<foo dc:names='Document.dc.Rights'>dc:AllRightsReserved</foo>
<foo dc:names='Document.dc.Relation'>http://www.dot.com/Valuation.2001-06-30.html</foo>
<foo dc:names='Document.dc.Source'>Argus</foo>
<foo dc:names='Document.dc.Subject'>Real Estate</foo>
<foo dc:names='Document.dc.Type'>dc:ValuationReport</foo> 
Extensible Hypertext Markup Language (xhtml)
The html token provides information for xhtml attributes.
<foo dc:names='Resource.html.class'>put CSS selector names here </foo>
<foo dc:names='Resource.html.style'>put html style attribute value here.</foo>
<foo dc:names='Resource.html.dir'>put html writing direction here.</foo> 
Web Service Description Language (WSDL)
The wsdl token provides direct access to WSDL-defined elements.
<foo dc:names='Resource.wsdl.???'>???</foo> 
xml Schema Datatype (XSD)
The xsd token provides direct access to XSD-defined elements for native datatypes.
<foo dc:names='Resource.xsd.string'>some string</foo>
<foo dc:names='Resource.xsd.boolean'>true</foo>
<foo dc:names='Resource.xsd.decimal'>1.0</foo>
<foo dc:names='Resource.xsd.float'>12.78e-2</foo>
<foo dc:names='Resource.xsd.double'>1267.43233E12</foo>
<foo dc:names='Resource.xsd.duration'>P0Y1347M0D</foo>
<foo dc:names='Resource.xsd.dateTime'>1999-05-31T13:20:00-05:00</foo>
<foo dc:names='Resource.xsd.time'>13:20:00-05:00</foo>
<foo dc:names='Resource.xsd.date'>1999-05-31</foo>
<foo dc:names='Resource.xsd.gYearMonth'>1999-05</foo>
<foo dc:names='Resource.xsd.gYear'>1999</foo>
<foo dc:names='Resource.xsd.gMonthDay'>05-31</foo>
<foo dc:names='Resource.xsd.gDay'>31</foo>
<foo dc:names='Resource.xsd.gMonth'>05</foo>
<foo dc:names='Resource.xsd.hexBinary'>0FB7</foo>
<foo dc:names='Resource.xsd.base64Binary'>...</foo>
<foo dc:names='Resource.xsd.anyURI'>http://www.dataconsortium.org</foo>
<foo dc:names='Resource.xsd.QName'>dc:ValuationReport</foo> 
Alternatively, an xsd:names attribute can be used, referencing the namespace identified by URI: http://www.w3.org/2001/XMLSchema-datatypes.
<foo xsd:names='string'>some string</foo>
<foo xsd:names='boolean'>true</foo>
<foo xsd:names='decimal'>1.0</foo>
<foo xsd:names='float'>12.78e-2</foo>
<foo xsd:names='double'>1267.43233E12</foo>
<foo xsd:names='duration'>P0Y1347M0D</foo>
<foo xsd:names='dateTime'>1999-05-31T13:20:00-05:00</foo>
<foo xsd:names='time'>13:20:00-05:00</foo>
<foo xsd:names='date'>1999-05-31</foo>
<foo xsd:names='gYearMonth'>1999-05</foo>
<foo xsd:names='gYear'>1999</foo>
<foo xsd:names='gMonthDay'>05-31</foo>
<foo xsd:names='gDay'>31</foo>
<foo xsd:names='gMonth'>05</foo>
<foo xsd:names='hexBinary'>0FB7</foo>
<foo xsd:names='base64Binary'>...</foo>
<foo xsd:names='anyURI'>http://www.dataconsortium.org</foo>
<foo xsd:names='QName'>dc:ValuationReport</foo> 
xml Linking Language (XLL)
The xll token provides direct access to XLL-defined attributes.
<foo dc:names='Resource.xll.type'>simple</foo>
<foo dc:names='Resource.xll.show'>new</foo>
<foo dc:names='Resource.xll.actuate'>onRequest</foo>
<foo dc:names='Resource.xll.title'>Views of the Property</foo>
<foo dc:names='Resource.xll.role'>pictureList</foo>
<foo dc:names='Resource.xll.href'>put a URL here</foo> 
Alternatively, an xll:names attribute can be used, referencing the namespace identified by URI: http://www.w3.org/1999/xlink.
<foo xll:names='type'>simple</foo>
<foo xll:names='show'>new</foo>
<foo xll:names='actuate'>onRequest</foo>
<foo xll:names='title'>Views of the Property</foo>
<foo xll:names='role'>pictureList</foo>
<foo xll:names='href'>put a URL here</foo> 
Electronic Business Card (vCard)
The vc token provides direct access to elements and attributes defined by the vCard protocol as specified by the Internet Mail Consortium.
<foo dc:names='Actor.vc.fn'>John Quincy Adams</foo> 

3 X/HTML Markup Rules

This section provides rules for and examples of the use of the dotted-name convention within Extensible html (xhtml) files. A Modular HTML specification will be created (see Modularization of XHTML™ in XML Schema).

Declaring the Dictionary

The first step in a datastream that uses the dotted-name conventions is to declare the namespace that is used as a prefix to the names attribute placed onto <foo> elements. The xml Namespace facility allows any name for the prefix to be assigned.

<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
    <body>
        <span>Report Begin Date:</span>
        <span pfx:names='Document.ReportingPeriod.1.BeginDate.iso'>2001-01-01</span>
    </body>
</html>

Declaring the Document

The next step is to declare the type of document that is being represented. There are two places conventionally where this information is specified for the benefit of receiving software: the <body> and <form> elements.

<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
    <body pfx:names='QuarterlyREIFReport'>
        <span>Report Begin Date:</span>
        <span pfx:names='Document.ReportingPeriod.1.BeginDate.iso'>2001-01-01</span>
    </body>
</html>
When nested elements in the datastream each have dotted-names attached to them, then it may be assumed that the nested element's names are qualified by its parent elements' names. For the sample, software can implicitly interpret <foo pfx:names='Document.ReportingPeriod.1.BeginDate.iso'/> as <foo pfx:names='QuarterlyREIFReport.Document.ReportingPeriod.1.BeginDate.iso'>.

However, because a "QuarterlyREIFReport" is a "Document", then it inherits its superclasses' attributes. Software must interpret "QuarterlyREIFReport.Document..." as "QuarterlyREIFReport...". This rule holds for consecutive terms, where the lagging term is a name of a "type" assigned to the leading term.

Declaring a Named Value

A namespace qualified names attribute may contain more than one name for the element's text content. An unqualified names attribute is not acceptable. A name attribute can also be used in the context of forms.

<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
    <body pfx:names='QuarterlyREIFReport'>
        <span>Report Begin Date:</span>
        <span pfx:names='Document.ReportingPeriod.1.BeginDate.iso'>2001-01-01</span>
        <h1 pfx:names='Document.Title.text Document.dc.Title'>Quarterly Real Estate Investment Fiduciary Report</h1>
    </body>
</html>

Declaring a Value

The text content for an element bearing a names attribute may be provided in different ways. For <input> elements, the value attribute contains the text to assign to the named value. For <select> elements, the value attribute on its child <option> element bearing a selected attribute is used. Below, one of the <option> elements contains an empty string, meaning that no assignment is to be made to the named value. There is no difference between an empty string and a non-existent value attribute.

<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
    <body pfx:names='QuarterlyREIFReport'>

        <!-- show the coding for any <input> element -->
        <input pfx:names='Document.dc.Date Document.ReportingPeriod.1.BeginDate.iso'  
               type='hidden'value='2001-01-01'/>

        <!-- show the coding for an <h1> element -->
        <h1 pfx:names='Document.Title.text Document.dc.Title'>
               Quarterly Real Estate Investment Fiduciary Report
        </h1>

        <!-- show the coding for a <select> element -->
        <select pfx:names='Document.type'>
            <option value='' selected='selected'>Quarterly Status</option>
            <option value='YearEndReport'>Year-end Report</option>
        </select>

    </body>
</html>

4 Linguistic Model

Named Value = [Datastream.] NamedValue | NamedNode + Value
The objective is to provide a structured name for a "named value" that is either a node in a logical data schema or one in an xml document object model. Both models appear simultaneously within xml markup, that is, within a datastream. The name of the datastream can be implied by the environment. Structured names correspond to a set of nested xml elements that can be generated from the name.

NamedValue = Resource.Attribute.DataType [.ConcatenationIndex]
A named value within a datastream is a named attribute of a resource identified within the datastream; named value names need to name both the resource and attribute to which the value applies. A single named value can be equally provided using any of a number of datatypes; named value names need to identify which datatype is being provided. For strings, a single named value may be split among multiple xml elements; a named string value needs to identify which position it occupies in a reconstituted, complete, string value.

Resource = [RelatedResource.] QualifiedResource [.Index] [.Qualifier]
A named value needs to identify specifically the resource for which it is an attribute. A resource can be identified by another resource with which a notable relationship exists, as well as by a notable, nameable characteristic of the resource. An indicative resource name must identify an instance of a resource. If multiple resources with an identically-named related resource and characteristic exist, then they must be distinguished by numeric indexes unique within the context of the related resource. The same qualifier named as a prefix may also be named as a suffix; qualifiers of a resource are equally attributable as a resource themselves. In effect, the prefixing suffix acts as a selector from a set of resources having the qualifier as part of its instance data schema. The implied RelatedResource is the Datastream, and the implied Index is '1'.

RelatedResource = Resource [.Predicate]
A resource is related to another resource through a predicate, that is, a verb. When not provided, the implied value for a predicate is 'relatedTo' however the specific implied value depends upon the types of the resources adjacent to one another. The Dictionary contains the following default relationships between resources of a type.
↓ A.B →ActorDocumentEntryEventLocationProductPropertyServiceTopic
ActorA.isA.B
A.partOf.B
A.saidBy.BA.had.BA.changedBy.BA.held.BA.provided.BA.describedBy.B
DocumentA.said.BA.isA.B
A.partOf.B
A.said.B
EntryA.hadBy.BA.isA.B
A.partOf.B
A.hadBy.B
EventA.changed.BA.isA.B
A.partOf.B
A.changed.B
LocationA.heldBy.BA.saidBy.BA.had.BA.changedBy.BA.isA.B
A.partOf.B
A.held.BA.is.BA.provided.B
ProductA.heldBy.BA.isA.B
A.partOf.B
PropertyA.is.BA.isA.B
A.partOf.B
ServiceA.providedBy.BA.providedBy.BA.isA.B
A.partOf.B
TopicA.described.BA.described.B
To provide an attribute for a Topic itself, then a predicate must be specified, for example, "Company.FinancialInformation.had.AsOfDate.text". Without the predicate, that is, if "Company.FinancialInformation.AsOfDate.text" was specified, then the "AsOfDate" applies to the Company, not to the FinancialInformation topic. Similarly, if a document is to be associated with an Entry, then "Entry.relatedTo.Document" is used.

Predicate = [Adverb.] EventType
Events are occurrences (past, present or future) of actions of and between resources. Events are named in the past tense, e.g., "Purchased", however the Dictionary also identifies its noun form, e.g., "Purchase".

QualifiedResource = [Qualifier.] ResourceType | QualifiedResourceType
A qualified resource is a type of resource that is qualified by a notable characteristic. A qualified resource type is a subclass of a resource-type, that is, every instance of a qualified resource type is equally an instance of the resource-type. A qualified resource identifies instances that are (1) an instance of a resource-type defined in the Dictionary (2) an instance of a qualified resource-type defined in the Dictionary (3) a qualified instance of a resource-type defined in the Dictionary (4) a qualified instance of a qualified resource-type defined in the Dictionary

ResourceType = ActorType | DocumentType | LocationType | ProductType | PropertyType | ServiceType
A resource-type is (a subclass of) any of six types of resources.

Index = 1|2|3|...
The numeric index identifies the position that a resource occupies in an array of resources 'had' by a related containing resource. When not specified, its implied value is '1'.

Qualifier = 'Past' | 'Present' | 'Future' | ... | EventType

Attribute = [TopicType.] EntryType [.QualifiedEntry]*
Attributes of a resource can be arranged as attributes of a topic of a resource; an attribute of a topic of a resource are equally attributes of the resource to which the topic relates. The attributed resource itself is the topic implied for attributes of the resource.

TopicType = ActorTopicType | DocumentTopicType | LocationTopicType | ProductTopicType | ServiceTopicType

EntryType = MemoType | QuantityType |TimeType

QualifiedEntryType = TimeQualifiedEntry | MethodQualifiedEntry | ...

Datatype = text | Language | Currency| NumericFormat | TimeExpression
Language = de|en|fr|it|sp|...
Currency = eur|usd|pso|pnd|...
NumericExpression = value|int|decimal
TimeExpression = iso|yr|mon|day|qtr|hr|min|sec|tz

ConcatenationIndex = 1|2|3|...
The concatenation index identifies the sequential ordering of substrings within a text value.