The <ExtendedProperties> element defines additional property names and types for usage within the current Dataset. These are effectively implemented as name-value pairs that can be used in subsequent Person, Animal, Place, Group, or Event entities.
<ExtendedProperties>
[ <PersonProperties> PROPERTY_DEF ... </PersonProperties> ]
[ <PlaceProperties> PROPERTY_DEF ... </PlaceProperties> ]
[ <GroupProperties> PROPERTY_DEF ... </GroupProperties> ]
[ <AnimalProperties> PROPERTY_DEF ... </AnimalProperties> ]
[ <EventProperties> PROPERTY_DEF ... </EventProperties> ]
</ExtendedProperties>
<PropertyDef Name=’prefix:name’ [Type=’type’] [Units=’units’]
[SemType=’sem-type’] [ItemList=’boolean’/>
{ <Property Name=’name’ [Key=’key’] [Value=’value’]
[Units=’units’] [DATA_ATTRIBUTE] ... >
</Property> }
|
{ <Property Name=’name’>
{ <Item [Key=’key’] [Value=’value’] [Units=’units’]
[DATA_ATTRIBUTE] ... >
</Item> } ...
</Property> }
For Properties that accept the optional Value attribute, the value defaults to the original written value if the attribute is absent. This presumes that the original written value is syntactically valid for the given data-type. For multi-value Properties, the orig-text may be a single datum if an individual item cannot be separated entirely. Any individual non-blank text is taken to be more specific than an amalgamation.
For custom Properties, as opposed to the predefined STEMMA ones, a namespace prefix should be present. See Extended Vocabularies. In the case of Properties of type EnumList (including its derivations) then each term may have such a prefix, e.g.
Value=“pre1:Term1.pre2:Term2”
The list of valid data-types may be found at: Data Types. See Extended Vocabularies for defining custom data-types. The semantic type is indicated by the SemType attribute which may use the Dublin Core vocabulary, e.g. SemType=’DC:title’ or SemType=’DC:publisher’.
Q: Should there be a variant of the ‘Text’ data-type that corresponds to text in particular language. For instance, in order to distinguish the name of an article — which may be in English — from a textual reference code (e.g. RG13) which would be language-independent?
When defining a Property, the Units attribute can provide a list of valid unit names, separated by commas, with the default being the first one. An example of this is used to define the STEMMA ‘Age’ property at Properties.
If ItemList is true (i.e. ‘1’) then the value may be a list of items, each of which is represented using an <Item> element. If the value has associated Units then the respective attribute will be on the <Item> element. In the case of a list containing a single value, the non-ItemList syntax is acceptable even though ItemList was true.
For example:
<Dataset Name=’Example’ xmlns:t=’http://example.com/types’>
<ExtendedProperties>
<PersonProperties>
<PropertyDef Name=’t:PlaceOfEducation’ Type=’PlaceRef’/>
</PersonProperties>
</ExtendedProperties>
A sample reference might be:
<Event Key=’eGraduation’>
<Type> Education </Type>
<SubType> Enrolment </SubType>
<When> 1974-06 </When>
<SourceLnk Key=’sGraduation’>
<PersonLnk Key=’pMe’>
<Property Name=’Name’> A. C. Proctor </Property>
<Property Name=’t:PlaceOfEducation’ Key=’wCollege’/>
</PersonLnk>
<PlaceLnk Key=’wPeoplesCollege’>
<Property Name=’Name’> People’s College </Property>
</PlaceLnk>
</SourceLnk>
</Event>
Notice that as well associating a reference to a named person with an equivalent Person entity, it also associates the reference to a named place with a corresponding Place entity. This has significant advantages if you want to make use of organised Place entities rather than simple place names. The lesser alternative would have been to declare the PlaceOfEducation Property as having a mere Text value. See also the Source entity which provides a way of assembling profiles from the subject references in a source — thus allowing analysis to be performed before making those associations to actual conclusion entities.
Let’s look at an example for Height and Weight Properties which would require the optional Units attribute.
<ExtendedProperties>
<PersonProperties>
<PropertyDef Name=’t:Height’ Type=’Measure’ Units=’cm,inch’/>
<PropertyDef Name=’t:Weight’ Type=’Measure’ Units=’kg,lb’/>
</PersonProperties>
</ExtendedProperties>
A sample reference might be:
<Event Key=’eEnlistment’>
<Type> Military </Type>
<SubType> Enlistment </SubType>
<When> 1914-06 </When>
<SourceLnk Key=’sEnlistment’>
<PersonLnk>
<Property Name=’Name’> W. H. Jones </Property>
<Property Name=’t:Weight’ Units=’kg’ Value=’72.3’> 11st 5lb </Property>
<Property Name=’t:Height’ Units=’inch’ Value=’71’> 5ft 11in </Property>
</PersonLnk>
</SourceLnk>
</Event>
No list of accepted units is prescribed here, although the Property definition can declare the accepted units using a comma-separated list in a Units attribute. Either the full name or the standard abbreviation may be used, together with the correct prefix if relevant (e.g. cm). Care should be taken not only to differentiate metric from imperial units, but also the UK/US differences for gallons, pints, tons, ounces, etc., wet and dry differences such as ounces versus ‘fluid ounces’, and nautical miles.