#225 Upgrading vCard

pending
5
2016-06-16
2012-07-24
No

The controled annotations described in section 6 of the specification use an RDF version of vCard version 3, defined by
http://www.w3.org/2001/vcard-rdf/3.0# based on http://tools.ietf.org/html/rfc2426

vCard was upgraded shortly after we released the proposal for annotations, and version 4 has been around for the last 6 years. defined in http://tools.ietf.org/html/rfc6350, it also exists in XML (xCard), But since we use the RDF version, we should use what is defined at:http://www.w3.org/2006/vcard/ns#

There are consequences on some elements:
* "Family" becomes "family-name"
* "Given" becomes "given-name"
* "EMAIL" becomes "email"
* "Orgname" becomes "organization-name"

Discussion

1 2 > >> (Page 1 of 2)
  • Chris Myers

    Chris Myers - 2012-07-25

    I am accepting this issue as valid.

     
  • Sarah Keating

    Sarah Keating - 2012-07-25

    I am accepting this issue as valid.

     
  • Lucian Smith

    Lucian Smith - 2012-07-25

    I agree with the proposed change and that it should be done.

     
  • Michael Hucka

    Michael Hucka - 2012-07-26

    I agree with the proposed change and that it should be done.

     
  • Michael Hucka

    Michael Hucka - 2013-09-14
    • status: open --> accepted
    • assigned_to: Nicolas Le Novère
    • Group: --> Accept-conformance-implications
     
  • Frank Bergmann

    Frank Bergmann - 2013-09-14

    I am accepting this issue as valid.

    I'm also worried about this, it will cause issues with software, and so it ought to hold for L3v2 / L2v5. It will cause a lot of issues for people not using libsbml, as then they need to figure out what vcard format to write out, based on the level / version. I would be happy to continue using the old vcard format, as I don't really see much benefit to our users.

     
  • Nicolas Le Novère

    I agree that we should probably not change that for L2V5. As for L3V2, I think we should aim at reusing existing standards as much as possible. The changes are not big, and it will be easy for software to support both forms, even if they do not use libsbml. However, it will make the direct use of SBML RDF annotation in semantic web context easier. What about adding the new construct and deprecating the old ones? So people should use the new ones, but the old ones are still valid.

     
    • Michael Hucka

      Michael Hucka - 2013-09-16

      I like that solution: deprecate the old format but still accept it.

       
  • Lucian Smith

    Lucian Smith - 2014-06-12
    • status: accepted --> open
     
  • Dagmar Waltemath

    I agree with the proposed change and that it should be done (original proposal to upgrade vCard).

    I also second the solution to depricate the old format but still accept it.

     
  • Lucian Smith

    Lucian Smith - 2014-06-27

    Copied from https://sourceforge.net/p/sbml/sbml-specifications/209/ , which is now closed as a duplicate of this issue:


    I have now managed to write this up and checked it into SVN for L3v2 only, not L2v5, as per Nicolas's suggestion. As per Mike's suggestion, most of the text is the same, but I now say, "Alternately, you can use vCard v4" and then spell out what that looks like. I did change 'vCard:N' to 'vCard4:FN' (i.e. full name instead of name (with 'given name' and 'family name' children), since Nicolas indicates this is becoming more often used.

    I also did not say anything about deprecation, merely that you could use either format. I would imagine that we would not remove the option to use v3 from SBML L3, regardless of how many versions we move to, and I don't think there's a need to warn people about it for a putative SBML L4, which might continue to allow vCard 3 and vCard 4 anyway.

    Nicolas and Dagmar, I would appreciate it if you in particular would look over what I wrote up for this (changes are in section 6.6), to make sure I didn't say anything erroneous, as you are our resident experts on annotation.

    The changes have been updated into SVN, and, pending editorial approval, will be incorporated into the upcoming SBML L3v2 specification. No changes along these lines will be made for the SBML L2v5 specification.

    If the editors vote differently, these changes will be reverted and/or added to the L2v5 specification as well.

    Draft specification (with these changes) available at:

    https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-2/core/spec/sbml-level-3-version-2-core.pdf

     
  • Frank Bergmann

    Frank Bergmann - 2014-06-28

    what i see in the L3V2 document does not quite look how i envisioned vcard4, I was expecting to see:

    • hasName
    • family-name
    • given-name
    • hasEmail
    • organization-name

    which is also what we use in the combine archive: http://co.mbine.org/specifications/combine_archive-Draft1.pdf

    In any case accepting both vcard forms is the way to go.

     
    • Lucian Smith

      Lucian Smith - 2014-07-07

      Hmm, it seems like you are correct and the original poster of this issue was incorrect: 'hasEmail' seems to be the correct form, and not 'email', and organization-name replaces 'ORG', not just 'Orgname'.

      However, I intentionally changed 'N' to 'FN' (though it seems I should have used 'fn') in light of Nicolas's recommendation that we switch from using the broken-up form of a name to simply using the full name as a string instead.

      I still think that's a good idea, but I wouldn't be adverse to also allowing 'hasName' (i.e. the broken-down form of the name) as well. Any opinions?

       
  • Brett Olivier

    Brett Olivier - 2014-06-30

    Accepting both versions of vcard works for me.

     
  • Lucian Smith

    Lucian Smith - 2014-07-08

    OK, a few more changes to correct my mistakes in the vcard4 names of things, plus additionally allow the 'hasName'/'family-name'/'given-name' form in vcard4 (as well as 'fn' for full name).

    Also, enough editors have signed off on the change, so it has now been officially accepted, and will appear in the forthcoming L3v2 specification.

     
  • Lucian Smith

    Lucian Smith - 2014-07-08
    • status: open --> closed
     
  • Lucian Smith

    Lucian Smith - 2014-07-08

    (Also, added to the list of design changes for L3v2.)

     
  • Lucian Smith

    Lucian Smith - 2016-06-03
    • status: closed --> open
     
  • Lucian Smith

    Lucian Smith - 2016-06-03

    Re-opening this to decide how to handle incorporating this change into l3v1r2 vs. l3v2.

    As it stands, the current draft of both new specifications simply say that you can now use vcard4, and don't say that you should use vcard4 over vcard3 (i.e. the idea of 'deprecating' vcard3 is not present). Should we deprecate vcard3 for both l3v1r2 and l3v2? Or only for l3v2? Or for neither? What is meant by 'deprecating' in this case anyway?

     
  • Sarah Keating

    Sarah Keating - 2016-06-03

    'deprecating' => new users should not use but existing software will still work.

    Again I argue add vcard4 to L3V1r2; state that vcard3 will be deprecated in L3V2 and do teh deprecation in L3V2.

     
    Last edit: Lucian Smith 2016-06-03
    • Lucian Smith

      Lucian Smith - 2016-06-03

      Do you envision any validation warnings being added in L3v2 to support the deprecation? Or will it just be a sort of 'best practices' text in the specification itself? If it's just the latter, we could add that text to both.

       
  • Sarah Keating

    Sarah Keating - 2016-06-04

    If a model contins an annotation that does not quite match the proscribed sbml-miriam-rdf then it is considered to be a.n.other rdf annotation for which there are no restrictions. So it is impossible to tell absolutely if the annotation was intended to be the sbml-miriam-rdf (with possibly a mistake) or a users own rdf annotation.

    Currently we have no explicit validation rules about the content of annotations. I would not anticipate adding any.

    We already have the annotations section that is really the 'best practice' for annotations if you want to encode this information in a way that other software will also interpret. So I think just reiterating that from L3V2 we recommend the use of vcard4 as we are considering vcard3 to be deprectaed. So in the L3V2 spec we just use the vacrd4 examples.

     
  • Brett Olivier

    Brett Olivier - 2016-06-08

    I support allowing vcard4 in L3V1r2 and deprecating it in L3V2 (with examples etc. as per Sarah's suggestion)

     
  • Dagmar Waltemath

    I support allowing vcard4 in L3V1r2 and deprecating it in L3V2 (with examples etc. as per Sarah's suggestion)

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks