#441 fDecl doesn't allow att.datcat yet

GREEN
open-accepted
5(default)
2013-10-10
2012-09-20
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 > >> (Page 1 of 2)
  • Lou Burnard

    Lou Burnard - 2012-09-21
    • milestone: --> GREEN
    • assigned_to: nobody --> louburnard
     
  • Lou Burnard

    Lou Burnard - 2012-09-21

    I think this is an oversight. Piotr?

     
  • Piotr Banski

    Piotr Banski - 2012-09-21

    Definitely an oversight. May I grab this one?

     
  • Lou Burnard

    Lou Burnard - 2012-09-23
    • assigned_to: louburnard --> bansp
    • status: open --> open-accepted
     
  • Lou Burnard

    Lou Burnard - 2012-09-23

    Have added it to class: leaving it to you to add some comment / example in the chapter if you think it necessary'; otherwise just close the ticket

     
  • Piotr Banski

    Piotr Banski - 2012-10-25

    At the risk of disturbing the anthill let me ask: isn't adding fDecl to att.datcat analogous to adding <equiv> to it (= something that we explicitly rejected) rather than to adding <f> to it?

    In other words, what's the semantics of fDecl with dcr:datcat as opposed to the semantics of <f> with @dcr:datcat? Or, in other words, shouldn't this be handled *inside* the fDecl, by an <equiv>/@uri?

    To be sure, I support Menzo's need to provide equivalence/alignment information at the level of fDecl, but I'm beginning to wonder if using dcr:datcat on fDecl *directly* expresses what we want expressed here.

     
  • Laurent Romary

    Laurent Romary - 2012-10-25

    I would leave out the issue of <equiv> here, which is a real one.
    The point of fDecl is clearly to avoid making a link on each f to assert its semantics.

     
  • Piotr Banski

    Piotr Banski - 2012-10-25

    Laurent, I'm not happy meddling in this ticket today, but it seems to me that the point of fDecl is to declare a feature.

    The use of @datcat on fDecl seems unfortunately to mean: this fDecl acts as such-an-such category. But the fDecl is not meant to act as (= be aligned with) a category: it is the <f> that is being declared that should be aligned, not the <fDecl>.

    Once again, I fully concur with the idea of expressing this information in FSD. I'm increasingly uneasy about the technical solution proposed here though. And we don't want to put in stuff that we are going to pull out in half a year, do we. :-/

     
  • Laurent Romary

    Laurent Romary - 2012-10-25

    Agree. I need to ponder upon this a little....

     
  • Menzo Windhouwer

    I interpret it as that the <fDecl/> declares to which data category the <f/> should be equivalent. Just like the <fDecl/> does that for the type the f value should have. If that role is better suited in TEI for <equiv/> then that could be the proper construct to use. However, it could lead to inconsistencies between the FDS and FSR mechanisms:

    Given the following FSD:

    <fsDecl type="WordForm">
    <fDecl
    name="writtenForm">
    <equiv uri="http://www.isocat.org/datcat/DC-1836"/>
    <vRange><vNot><string/></vNot></vRange>
    </fDecl>
    <fDecl
    name="grammaticalNumber">
    <equiv uri="http://www.isocat.org/datcat/DC-1298"/>
    <vRange><vAlt>
    <symbol value="singular">
    <equiv uri="http://www.isocat.org/datcat/DC-1387"/>
    </symbol>

    </vAlt></vRange>
    </fDecl>
    </fsDecl>

    and FSR

    <fs type="WordForm">
    <f name="writtenForm">
    <string>clergyman</string>
    </f>
    <f name="grammaticalNumber">
    <symbol value="singular"/>
    </f>
    </fs>

    this FSR and FSD combination should be equivalent to

    <fs type="WordForm">
    <f name="writtenForm" dcr:datcat="http://www.isocat.org/datcat/DC-1836">
    <string>clergyman</string>
    </f>
    <f name="grammaticalNumber" dcr:datcat="http://www.isocat.org/datcat/DC-1298">
    <symbol value="singular" dcr:datcat="http://www.isocat.org/datcat/DC-1387"/>
    </f>
    </fs>

    Of course any tool interpreting the FSD can make this transition from <equiv/> to @dcr:*, but is it really needed? Introducing <equiv/> would touch maybe more then wanted, e.g., in my example I also used <equiv/> to express the data category equivalence for the singular symbol. As FSR and FSD share <symbol/> <equiv/> would also become part of the FSR. The same is true the other way around @dcr:* is available for <symbol/> in the FSR so also in the FSD. In my view it would be strange to use <equiv/> in one part of the FSD and @dcr:* in another part ...

    Just my 2 cents ...

     
  • Piotr Banski

    Piotr Banski - 2012-10-25

    I take the point about <equiv>. On the other hand, I also see an issue concerning the variable interpretation of the dcr: attributes, where, I believe -- and I think this belief is shared by some members the Council, after some exchanges on the topic in the past and now -- there should be one simple interpretation ("*I* am aligned with this-and-that").

    What we have here is, I daresay, an obvious case where we should *not* feel ready to commit ourselves to one view -- there's still a few paths left open. I would therefore like to follow a suggestion that I have got, to withdraw Lou's modification before the release, and bring it back after the release, while leaving this ticket open.

     
  • Laurent Romary

    Laurent Romary - 2013-08-12

    Where do we stand with this? I think we need to alter slight the policy "I am this" when it applies to element declaring the semantics of others (equiv and fDecl are two similar cases). For tsuch elements, the dcr: attributes would mean: "what I declare here is equivalent to this entry in the DCR"

     
    • Piotr Banski

      Piotr Banski - 2013-08-12

      That would mean semantics conditioned upon semantics, a pretty nasty dependency.

      How about targetting this squarely and setting up something analogous to @targetLang, with the precise semantics mentioned above?

       
  • Laurent Romary

    Laurent Romary - 2013-08-12

    Can you elaborate on that? You mean having an additional dcr: attribute?

     
    • Piotr Banski

      Piotr Banski - 2013-08-12

      After having pondered on this for a while, I think now that it might be good to make ISO FSD (ISO 24610-2:2011) aware of other ISO standards, as is, well, standard.

      This time, it would be nice if ISO FSD was made aware of the existence of ISO DCR and allowed for what we've talked about in this ticket. It seems to me that this is the direction where the effort should be going, otherwise the TEI is pressed into patching what other bodies should have fixed by now.

       
  • Laurent Romary

    Laurent Romary - 2013-08-12

    Well in this case, ISO FSD will just take up what the TEI suggests, because a) this is where most appropriate experts are and b) we should normally expect more reactivity on the side of the TEI. So for me the TEI is the place to experiment/implement. We should thus not procrastinate this too long...

     
  • Lou Burnard

    Lou Burnard - 2013-08-12

    I agree that FSD is in serious need of an update. It has not changed
    substantially for many many years. I'm just not sure who the "other
    bodies" are who might do this -- the workgroup in TC37 has not so far as
    I know done much lately. It's a joint ISO/TEI workgroup, but it needs
    revitalising from both sides.

    On 12/08/13 10:56, Piotr Banski wrote:

    After having pondered on this for a while, I think now that it might
    be good to make ISO FSD (ISO 24610-2:2011) aware of other ISO
    standards, as is, well, standard.

    This time, it would be nice if ISO FSD was made aware of the existence
    of ISO DCR and allowed for what we've talked about in this ticket. It
    seems to me that this is the direction where the effort should be
    going, otherwise the TEI is pressed into patching what other bodies
    should have fixed by now.


    *[bugs:#441] http://sourceforge.net/p/tei/bugs/441/ fDecl doesn't
    allow att.datcat yet *

    Status: open-accepted
    Labels: TEI: Definition of Elements/Attributes/Classes
    Created: Thu Sep 20, 2012 10:04 AM UTC by Menzo Windhouwer
    Last Updated: Mon Aug 12, 2013 08:23 AM UTC
    Owner: Piotr Banski

    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


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/tei/bugs/441/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #441

  • Laurent Romary

    Laurent Romary - 2013-08-12

    So, back to the actual issue. How to mark on fDecl the equivalence to an ISOCat entry. Piotr rejects the existing dcr: attributes since he says it is not the appropriate semantics. Is there a consensus on this? If yes, we need an extra mechanism. Another attribute? also in the dcr: namespace?

     
    • Piotr Banski

      Piotr Banski - 2013-08-12

      BTW, it's not that I had the whim to reject the use of the existing dcr: attributes: I have merely pointed at considerations and decisions made in an analogous case.

      To push the point further: there is nothing illogical in placing @dcr:datcat on an fsDecl or fDecl, to make sure that they are interpretable as data containers for declarations of feature structures or of features. That is in full accordance with DCR principles, and, in fact, this point alone should suffice to cut the discussion on the initial suggestion, and redirect it towards looking for a place and a method to define something like @targetDatcat.

       
  • Piotr Banski

    Piotr Banski - 2013-08-12

    Apart from the status of ISO/TEI FSD, one more issue that may need to be considered is that it may be expected that it's the "new" piece of the standards puzzle that should be responsible for defining bindings for the other standards, rather than forcing them to update.

    ISO DCR has done a good job by defining and namespacing its two attributes that can now be plugged into other descriptions. Possibly, what Laurent has mentioned above may be a good further step: to expect ISO DCR to update and extend its set of {@datcat, @valueDatcat} with two more attributes that can be used in schemas, notably in ISO FSD: {@targetDatcat, @targetValueDatcat}.

     
    Last edit: Piotr Banski 2013-08-12
  • 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]

     
  • Menzo Windhouwer

    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>
    
     
  • Menzo Windhouwer

    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?

     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks