Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#441 fDecl doesn't allow att.datcat yet

GREEN
open-accepted
Piotr Banski
5(default)
2013-10-10
2012-09-20
Menzo Windhouwer
No

TEI P5 2.1.0 says at the end of section 18.3

"Whether at the level of feature-system declarations, feature- and feature-value libraries, or individual features, it is possible to align both feature names and their values with standardized external data category repositories such as ISOcat."

However, a feature declaration can not be associated with an ISOcat data category using @dcr:datcat yet, i.e., <fDecl> [1] doesn't yet include the att.datcat [2] attribute set which <f> [3] already does.

If <fDecl> would allow @dcr:datcat it becomes possible to declare all relationships with ISOcat data categories in a feature system declaration instead of doing so highly redundant in each feature instantiation.

[1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-fDecl.html
[2] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datcat.html
[3] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-f.html

Related

Bugs: #441

Discussion

<< < 1 2 3 4 > >> (Page 3 of 4)
  • Laurent Romary
    Laurent Romary
    2013-08-12

    OK. Than let's define a proposal for these two attributes, liaise with Menzo and Sue-Ellen to fine-tune and have this adopted on booth side.

     
  • Laurent Romary
    Laurent Romary
    2013-08-15

    Here below, I put a comment from Menzo Windhouwer:
    [quote]
    If I understand correctly there were concerns due to the implicit indirection from a schema declaration to the instances, e.g., if you link a DC with @dcr:datcat to an element declaration in a schema it actually implies that the instance is linked to this DC. It's now proposed to make this explicit by using @dcr:targetDatcat and @dcr:targetValueDatcat. I've added support for this to the DC Reference schema. See DC Reference schema version 1.2 at (on the ISOcat test server, not yet on isocat.org):

    http://lux13.mpi.nl/isocat/12620/
    

    So these could be used by fDecl now, e.g.,

    <tei:fDecl name="partOfSpeech" dcr:targetDatcat="http://www.isocat.org/datcat/DC-1345">
    <tei:vRange>
    <tei:vAlt>
    <tei:symbol value="..."/>
    <tei:symbol value="commonNoun" dcr:targetValueDatcat="http://www.isocat.org/datcat/DC-1256"/>
    </tei:vAlt>
    </tei:vRange>
    </tei:fDecl>

    Do notice that as the tei:fDecl schema reuses tei:vRange the value declarations, e.f., tei:symbol in this case, should support both the dcr:target attributes and the 'old' dcr: attributes as these elements can also appear in an instance.

    Please let me know if I misunderstood or other solutions are preferred. If it's all correct I'll include this in the next update of isocat.org. And also update the FSD support of RELISH LMF (see http://tla.mpi.nl/relish/lmf/).

    [/quote]

     
  • Here is the fDecl example that gone missing in the previous post:

    <tei:fDecl name="partOfSpeech" dcr:targetDatcat="http://www.isocat.org/datcat/DC-1345">
        <tei:vRange>
            <tei:vAlt>
                <tei:symbol value="..."/>
                <tei:symbol value="commonNoun" dcr:targetValueDatcat="http://www.isocat.org/datcat/DC-1256"/>
            </tei:vAlt>
        </tei:vRange>
    </tei:fDecl>
    
     
  • Hi, All,

    Any consensus on this? I'm preparing an isocat.org update and would like to know if I can include the changes for TEI in the DC Reference RELAX NG schema.

    Thanks in advance,

    Menzo

     
  • Laurent Romary
    Laurent Romary
    2013-09-06

    I think your last proposal did not lead to any criticism. I would say you can move ahead. @others?

     
  • Piotr Banski
    Piotr Banski
    2013-09-06

    I'm happy to see this done so swiftly. Thank you, Laurent, for pushing this issue ahead and thank you, Menzo, for the implementation on the DCR side.
    And may I say that when this goes through, it will be practically immediately usable in the KorAP project, where we use FSR for annotations and our FSDs are being created right this month.

     
  • Lou Burnard
    Lou Burnard
    2013-09-06

    So what, concretely, is the proposal for change to the TEI here? Reviewing the discussion, Piotr's original objection to my hasty solution of adding <fsd> to the att.datcat class seems correct. The preferred solution should be to add dcr:targetDatCat to <fsd>

    We could do any of the following:

    (a) Nothing. Adding attributes from another namespace is always possible and does not perturb the schema. If we choose this option however, we really must make the possibility explicit in the text of the Guidelines, and supply an example.

    (b) Modify the att.datcat class soi that it also provides dcr:targetDatCat, possibly adding schematron rules to say that you can only inherit it if you are an <fsd> in which case you cannot inherit the other att.datcat attributes. This seems a bit tortuous.

    (c) Explicitly add the attribute to <fsd>

    (d) Define a new class att.refDatCat to supply the attribute and add <fsd> to it.

    If it's not obvious I would recommend either (a) or (c).

     
  • Laurent Romary
    Laurent Romary
    2013-09-06

    I would say d), because it could also be useful for elementSpec

     
  • You wouldn't put only <fsd> to the class att.refDatCat isn't it? Values appearing in the FSD, e.g, <tei:symbol> (see the example some posts earlier), should also use @dcr:targetDatcat or @dcr:targetValueDatcat instead of @dcr:datcat or @dcr:valueDatcat. Or did I understand the whole argument wrong?

     
    Last edit: Menzo Windhouwer 2013-09-06
  • Lou Burnard
    Lou Burnard
    2013-09-06

    On 06/09/13 11:40, Menzo Windhouwer wrote:

    You wouldn't put only to the class att.refDatCat isn't it? Values
    appearing in the FSD, e.g, (see the example some posts earlier),
    should also use @dcr:targetDatcat or @dcr:targetValueDatcat instead of
    @dcr:datcat or @dcr:valueDatcat. Or did I understand the whole
    argument wrong?

    (Menzo : if you meant to say "You wouldn't put only <fsd>..."
    remember you have to escape the pointy brackets !)

    This is a good argument for my suggestion (d) then, and since I see
    Laurent also prefers that, I guess that's the right choice.

    So we need (a) someone to draft the new class declaration (b) someone
    to specify the elements which should be members of that class (c)
    someone to write some appropriate text with examples for the Guidelines.

    I can help with (a) and possibly (c), though I'd rather Piotr or Menzo
    took a first stab at it. Is there a consensus on (b) ?

     
<< < 1 2 3 4 > >> (Page 3 of 4)