Hi Martin,

Let's forget the targetDatcat, it's been a while.

The datcat attributes generalise beyond FSR; actually, as far as I
recall, there was never a time where they would be used exclusively for
FSR; it's simply that feature structures provide an incredibly good
illustration of the usefulness of datcat :-).

Pieces of the datcat story can be traced here:

In your example, the @uri refers to the target of <equiv>, exactly to
prevent the use of datcat here, because it would be misleading -- both
of us participated in that discussion, back then ;-). (I think that we
might have considered something like targetDatcat at one point, and the
memory just stuck in my brain while @uri persevered...).

> <equiv name="orthography" uri=""/>

@datcat provides alignment with a feature (understood in abstract model
terms), while @valueDatcat privides alignment for a value of that
feature. In the TEI, this can be serialized as, e.g.:

<f name="part of speech" fVal="noun" />

but also as


and the datcat reference serves to say "I mean the same thing by
'f/name="part of speech"' and by 'pos'; furthermore, this thing is
defined as the concept #xxx in ISO DCR." Similarly with the value of POS
vs. @valueDatcat.

The trick is that the current element (<pos>) is one end of the
relation, with the other end sitting in ISOCat. This means that in your
example above, @dcr:datcat would align <equiv>, rather than the thing
that <equiv> points at. This is why @datcat can't be used there, and
@uri is used instead to say "what <equiv> points to should be aligned
with concept #xxy in ISO DCR".

The fact that the idea of abusing @datcat for aligning targets of
<equiv> returns may suggest that I have failed at wording the relevant
fragments of the Guidelines. I think that one guilty omission was the
fragment where I should have stated why the idea of having @datcat on
<equiv> is bad. And yes, @Lou, I know: "fix it!" is what I should do now...

I'm a bit uneasy as to where that fragment should go: in the definition
of <equiv>, it would be a bit out of place, because there are more
elements with this sort of targetting semantics (look among the
Documentation Elements), and it's not a good idea to have a list of
"attributes that one shouldn't think of using in this very element".

Maybe the note at the end of

would be a good place for such a warning (?).



On 29/10/14 18:39, Martin Holmes wrote:
> Hi Piotr
>> The datCat attributes are meant to declare the equivalence of the
>> element that they appear in, not the target element of that element.
>> There's targetDatcat, I think, too.
> @dcr:datcat and @dcr:valueDatcat are intended really to be used in feature/value systems where there are only two components, a name and a value:
> <f name="part_of_speech"
>   dcr:datcat="" fVal="#commonNoun"
>   dcr:valueDatcat=""/>
> In the case of this <equiv>, we have something quite similar:
> <equiv name="orthography" uri=""/>
> and I would have thought that by analogy with the example above, @dcr:datcat would specify the URI for the name attribute. However, you might also argue that @name is a "value" here, so you could use @dcr:valueDatcat:
> "contains a PID (persistent identifier) that aligns the content of the given element or the value of the given attribute with the appropriate simple Data Category (or categories) in ISOcat."
> Outside of feature-value libraries, though, it's quite difficult to be sure exactly what "the value of the given attribute" might be, when there are potentially lots of attributes on the host element. <seg>, for instance, can host these dcr: attributes; on a <seg> with @corresp, @xml:id, @xml:lang and @n, what would @dcr:valueDatcat be presumed to be referring to? I find this stuff very confusing, I must admit, although I've used it quite a lot in feature structure work.
> There's no @targetDatcat in TEI. 
> Martin Holmes
> [log in to unmask]
> ________________________________________
> From: TEI (Text Encoding Initiative) public discussion list [[log in to unmask]] on behalf of Piotr Bański [[log in to unmask]]
> Sent: October 29, 2014 3:12 PM
> To: [log in to unmask]
> Subject: Re: Question on declaring ISOcat values in ODD (Linguistic Dictionary)
> Hi Martin,
> The datCat attributes are meant to declare the equivalence of the
> element that they appear in, not the target element of that element.
> There's targetDatcat, I think, too.
> Best,
>   P.
> On 29/10/14 16:30, Martin Holmes wrote:
>> Hi Jack,
>> On the face of it, what you need are the att.datcat attributes:
>> <>
>> but they're not currently available on <equiv>. I don't see why they
>> shouldn't be, so if you also think they're the right way to do this, let
>> me know and I'll open a feature request.
>> Cheers,
>> Martin
>> Martin Holmes
>> [log in to unmask]
>> [log in to unmask]
>> [log in to unmask]
>> ------------------------------------------------------------------------
>> *From:* TEI (Text Encoding Initiative) public discussion list
>> [[log in to unmask]] on behalf of Jack Bowers [[log in to unmask]]
>> *Sent:* October 29, 2014 2:16 PM
>> *To:* [log in to unmask]
>> *Subject:* Question on declaring ISOcat values in ODD (Linguistic
>> Dictionary)
>> Hi,
>> I'm wondering if any linguistically oriented TEI people of with
>> knowledge of/experience with using ISOcat and ODD could tell me if I am
>> using the 'equiv' element correctly..
>> Below is an example of my 'elementSpec' in the ODD, I am looking to
>> declare that the TEI element 'orth' is equivalent to the ISOcat value
>> 'orthography' and whose PID is the value in the @uri:
>>     <elementSpecmodule="dictionaries"ident="orth">
>>      *<equivname="orthography"uri=""/>*
>>      <desc>The Mixtec working orthography is the orthographic system
>> adhered to in this corpus and it corresponds to that used in the
>> publications by SIL Mexico which are based on the recommendations
>> by <orgNamexml:lang="mix">Ve'e Tu'un Savi</orgName> (House of the Mixtec
>> language) for a unified orthographical system for all varieties of the
>> Mixtec language. The value of the attribute @<att>uri</att> is that
>> defined in the ISOcat registry and pertains to a non-language specific
>> orthographic system.</desc>
>>     </elementSpec>
>> Any comments, advice would be much appreciated!
>>  Thanks in advance,
>> Jack