#336 soft deprecation of @key

GREEN
closed
Lou Burnard
5
2013-06-21
2011-11-13
Kevin Hawkins
No

Per discussion at TEI Council meeting in Paris in November 2011, we agreed that uses of @key can all be handled by @ref, using ref="urn:<NID>:<NSS>". See RFC 2141 for the syntax of a URN and RFC 3406 for how a project might register a NID and thereby avoid collisions with other URNs.

Council's vision is that we would like to deprecate @key some day but that it's too widely used today to do so. As an interim measure, we will modify the Guidelines to make the point that people should switch to @ref wherever @key is mentioned.

Discussion

  • Kevin Hawkins
    Kevin Hawkins
    2011-11-13

    • assigned_to: nobody --> kshawkin
    • status: open --> pending
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-13

    • status: pending --> open
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-13

    As an alternative to using a URN with a non-registered NID, you could use ref="<scheme>:<hierarchicalpart>", which would effectively be identical to what's in the original ticket except without "urn:". Need to find someone who better understands these things to know which is better.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-13

    Note that if we decide that URN with a non-registered NID, we should consider revising att.readFrom and section 22.5 (#TDbuild) to recommend inserting "urn:" in front of "tei:" to make it a URN.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-20

    Previous comment should read:

    Note that if we decide to recommend a URN with a non-registered NID as an alternative to a URI with an unregistered scheme (ref="<scheme>:<hierarchicalpart>"), we should consider revising att.readFrom and section 22.5 (#TDbuild) to recommend inserting "urn:" in front of "tei:" to make it a URN.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-20

    Sebastian reported on tei-council on 2011-11-13 that "computer sciency types" at Oxford felt that a URI with a non-registered scheme was slightly less abusive.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-26

    For URI vs. URN, also see FR 2919640.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-12-04

    Kevin asked Michael Sperberg-McQueen to weigh in, and he wrote by email:

    The people I know who have spoken most eloquently on this topic
    (namely former colleagues at W3C) would all say "Why on earth
    not an http URL, so people who need to find out what the thing
    is can dereference the URI and find some useful information? If
    you are concerned about permanence, why not make it a PURL?"
    I'm not sure if they would have a preference as between the two options
    you mention.

    He also suggested contacting Eric Miller (formerly of OCLC and now of Zepheira).

     
  • James Cummings
    James Cummings
    2012-04-13

    I agree with the original ticket, for soft deprecation of @key.

    I'm less certain about whether we should be recommending URIs vs URNs but lean towards unregulated URIs at the moment.

    -James

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-04-16

    Per discussion in Ann Arbor, Kevin will choose URI or URN and carry out this ticket now (because it is going to happen regardless of the outcome of Martin's group) and then send my revision number to Lou for review the changes. But keep in mind that <country key="FR"/> should be left as key because it's not an internal scheme.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-05-20

    I have done further reading on URIs and URNs.

    We could propose use of a URI, either with a registered or unregistered scheme. RFC 4395 describes the procedure for registering schemes with the IANA. However, the bar for registration is fairly high: among other things, "New URI schemes SHOULD have clear utility to the broad Internet community" and "a URI scheme definition SHOULD define the applicable set of operations that may be performed on a resource using the URI as its identifier". It seems to me that most uses of @key would not satisfy these. While there are many unregistered (de facto) URI schemes in use today, but I don't think it's a good idea for the Guidelines to prescribe such practice since the point of registering schemes is to avoid collisions.

    As for URNs, I realize now that they aren't a good choice since RFC 2141 never advanced beyond being a proposed standard.

    However, the solution Syd proposed on http://purl.org/TEI/fr/2919640 -- for use of the IANA-registered "tag" URI scheme (as described in RFC 4151) -- appears to be exactly what we need as a replacement for a deprecated @key. This scheme explicitly does not require any registration of the name of the taggingEntity beyond what is already done through DNS registration (or having an email address).

    So I will change all uses of @key in examples in the Guidelines to use this format:

    ref="tag:example.org,2012:foo"

    except for those like <country key="FR"/> which already refer to a particular external vocabulary. I will also refer explicitly to RFC 4151 where appropriate for further guidance on constructing a value of @ref.

    Note that use of tag URIs does not prohibit any user of the TEI from using a registered or unregistered scheme on a URN or URI if they prefer.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-05-20

    Implemented at revision 10374. Reassigning to Lou to review.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-05-20

    • assigned_to: kshawkin --> louburnard
     
  • Kevin Hawkins
    Kevin Hawkins
    2012-05-20

    And also revision 10375.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-05-22

    ... and revision 10390.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-05-29

    ... and also revision 10404.

     
  • Lou Burnard
    Lou Burnard
    2012-06-17

    • status: open --> closed
     
  • Lou Burnard
    Lou Burnard
    2012-06-17

    This looks fine to me, so I am closing the ticket