[tei-council] Chapter 18 - Feature Structures

[Lou's Laptop]

Brett Zamir wrote:
> *
> 18.2 Elementary Feature Structures and the Binary Feature Value*
>
> Might the definition for <binary/> (not in source) add add the add a 
> clarification such as "(also called a Boolean value)".
>
The ISO workgroup responsible for this chapter (the text of which is now 
actually included in a published ISO standard!) was quite adamant on the 
fact that binary does not mean the same as boolean. Binary simply means 
two possible states -- with none of the semantics of true/false 
associated with boolean.


> *18.3 Other Atomic Feature Values
> *
> For <numeric/>, as there is no @min since <numeric/>'s @value 
> represents a lower bound, should mention be made that not indicating a 
> @max value means that the <numeric value=> has no bounds?
> *
> *
But it doesn't. If you specify only @value, then the lower and upper 
bound are the same.

> *18.4 Feature and Feature-Value Libraries*
>
> Is there a way to express feature value libraries with regular 
> expressions?
>
I'm not sure what you're getting at here, but if you mean can you 
express the value part of a feature value using a regexp, then the 
answer is no. You can only use members of model.featureVal (tho 
obviously a given regexp can be rewritten as say a vColl or vNot)

> *18.5 Feature Structures as Complex Feature Values*
>
> 1) What is the significance of <f name="rel"> <symbol value="LOVE"/> 
> </f>? Why is LOVE repeated here?
>

There is a feature whose name is "rel" and its value is a symbol "LOVE". 
I don't see any repetition.Oh, wait a minute: I see what you mean. The 
first occurrence of "love" (lower case) is the string value of a feature 
called "surface form". The one in uppercase is a symbolic value within 
some semantic system -- it's nothing to do with the word "love", it's 
the action (rel) which the word denotes.
 
> 2) Why would features #N1 (presumably a noun) be on an adjective?: <fs 
> xml:id="ADJ" type="adjective" feats="#N1 #V1"> or a verb feature in a 
> preposition: <fs xml:id="PREP" type="preposition" feats="#N0 #V0">
>
Yes, that is a bit odd, as is the fact that this example is a CDATA 
section instead of a proper egXML, which makes me suspiucious. Anyway 
the values used for the pointers are completely arbiytrary -- so I 
changed them to F1 F2 F3.


> 3) For the following:
>
> *In this case, we assume the existence of a feature library*
> containing specifications for the basic feature categories like the 
> following:
> <egXML xmlns="http://www.tei-c.org/ns/Examples"><fLib n="categorial 
> features">
>    <f xml:id="NN-1" name="nominal"><binary value="true"/></f>
>    <f xml:id="NN-0" name="nominal"><binary value="false"/></f>
>    <f xml:id="VV-1" name="verbal"><binary value="true"/></f>
>    <f xml:id="VV-0" name="verbal"><binary value="false"/></f>
> <!-- ... -->
> </fLib>
> </egXML>
> </p>
> <p>*With these libraries in place*, and assuming the availability of
> similarly predefined feature structures for transitivity and
> semantics, the preceding example could be considerably simplified:
> <egXML xmlns="http://www.tei-c.org/ns/Examples"><fs type="word">
> <f name="surface"><string>love</string></f>
>    <f name="syntax">
>     <fs type="category">
>       <f name="pos" fVal*="#V"/>*
>       <f name="val" fVal="#TRNS"/>
>     </fs>
>    </f>
>    <f name="semantics">
>     <fs type="act">
>       <f name="rel" fVal="#LOVE"/>
>     </fs>
>    </f>
> </fs>
> </egXML></p>
>
> The introductions to the examples would lead me to think that NN-1, 
> etc. might be used in the example, but in this case, it seems only to 
> have #V. Is this mistaken?
>
I've changed "these libraries" to "such libraries" which may help a bit. 
NN-1 etc are only there are examples.

> *18.7 Collections as Complex Feature Values
> *
> Is there a means to express that a given feature structure, in a 
> <vColl>, etc., is required or not?
>
Yes, that is what the FSD does.

> *18.8.1 Alternation
> *
> 1) "A better, and more general, way would be to represent the 
> alternation explicitly". Might there be an explanation here as to why 
> this is a better way?
>
I think of it as better because it seems more explicit to me, but maybe 
this is all so obscure that no-one would agree with me. I've deleted 
"better, and".


> 2) Why is "TEI P5" mentioned here:
>
>     "If a large number of ambiguities or uncertainties need to be 
> represented, involving a relatively small number of features and 
> values, it is recommended that a stand-off technique, for example 
> using the general-purpose <gi>alt</gi> element discussed in <!-- 
> section <ptr target="SAAT"/> of --> *TEI P5*, be used, rather than the 
> special-purpose <gi>vAlt</gi> element."
>
>
Ah, that;s because the text you;re looking at is the ISO text, which 
cannot reference back to sections of TEI P5.  Fixed.

> *18.11 Feature System Declaration
> *
> Might a reference here (or elsewhere) to OWL/RDF put this chapter into 
> a wider context given the metadata this chapter introduces:
>     "The scheme described in this chapter may be used to document any 
> feature structure system, but is primarily intended for use with the 
> feature structure representation defined by the ISO 24610-1:2006 
> standard, which corresponds with the recommendations presented in 
> these Guidelines"

Maybe: I;ll pass this suggestion on to the ISO workgroup (they are still 
working on revising the FSD section of this chapter)

>
> *18.11.1 Linking a TEI Text to Feature System Declarations*
>
> For the line, "Each <gi>fsDecl</gi> has a unique identifier, given as 
> the value of its <att>xml:id</att> attribute.", the example below it 
> does not have xml:id's on its <fsDecl>'s.
>

I think this is a slip. The paragraph whose beginning you cite is 
probably in the wrong place. Anyway, for the moment, I have just 
commented it out.

> *18.11.3 Feature Declarations*
>
> I think the various elements mentioned within the <vRange> and 
> <vDefault> definitions (not in source) ought to have "<" and ">" 
> brackets around them.
>
Indeed they should. And the descriptions need some revision for 
comprehensibility too.

> *18.11.4 Feature Structure Constraints*
>
> 1) I can't tell apart the definitions for <cond> and <bicond> (not in 
> source).
>
<cond> is satisfied if the antecedent does not subsume a given feature; 
<bicond> only if both antecedent and consequent do not.

> 2) Are &amp; supposed to be in the output at 
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/FS.html ?
>
Probably not, but you need to tell me more precisely where you spotted them

> 3) Might discussion be added in this section as to how these 
> constraints might be used with or instead of Schematron constraints?
>

Well, yes. Schematron is another way of implementing the constraints 
defined by a WSD (and one that has been suggested to the workgroup) but 
they haven't reviewed the possibility or its implications yet.