Yes, that’s exactly what I’m looking for. There is a complete, 
general-purpose, data-typed key-value data structure in TEI and I never 
noticed it. Wow.

Maybe the name threw me off. I’ve seen “key-, name- or attribute-value” 
but never “feature-value”. Is that specific to linguistic analysis? 
Maybe “18 Feature Structures” could be edited to highlight the general 
purpose nature of this part of TEI.

Using feature-value in <profileDesc> could be very helpful to those 
describing documents in Omeka. But <fs> could be used only down in 
<profileDesc><textClass><classCode>. Could it be added to <textClass> or 
even <profileDesc>?


On 12/8/2016 2:12 PM, Frederik Elwert wrote:
> Dear John,
> you should probably take a look at the feature structure system. That 
> seems to match you description.
> Best,
> Frederik
> Am Donnerstag, 8. Dezember 2016 19:24:00 CET schrieb John P. McCaskey 
> <[log in to unmask]>:
>> What is the best way to encode abstracts that are essentially just 
>> key-value pairs?
>> Consider formulaic abstracts such as these:
>> This document is a [writ|deed|charter]. The court of authority is 
>> [papal|secular]. The witness to the document is [insert someone’s name].
>> The inventor was [insert name]. The researched drug was [insert 
>> chemical name]. The test facility was [hospital|military 
>> facility|university].
>> Only the parameters are important. I don’t really need the 
>> introductory words.
>> I’m looking for something like this:
>> <abstract>
>>     <list>
>>         <item type="type">charter</item>
>>         <item type="court">secular</item>
>>         <item type="witness">someone’s name</item>
>>     </list>
>> </abstract>
>> But @type isn’t an attribute of <item> and <item> seems semantically 
>> wrong. <keywords> doesn’t work for key-value pairs. <classCode> 
>> doesn’t seem right. <catRef> seems overly complicated.
>> What is the best approach, sticking to the stock schema?
>> --