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:
[log in to unmask]" type="cite">Dear John,

you should probably take a look at the feature structure system. That seems to match you description.

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:
        <item type="type">charter</item>
        <item type="court">secular</item>
        <item type="witness">someone’s name</item>

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?