#209 Syntax of 'model history' too restrictive?

Closed - Duplicate
closed
nobody
5
2014-06-27
2012-01-31
No

For example, the SBML L2V4 specification does not list the element 'vCard:Middle' in the allowed syntax for model history (the 'vCard:N' element is very restricted there). The spec allows valid XML/RDF content in several other places, so I think it should only be fair to do so here too.

Discussion

  • Sarah Keating

    Sarah Keating - 2012-05-24

    I am accepting this issue as valid.

     
  • Sarah Keating

    Sarah Keating - 2012-05-24

    Camille is right. Our spec allows the creator to have name/org/email in any order with other rdf inbetween. However, within the name element no other rdf is allowed.
    Since more and more we are being asked to relax when "additional information" makes the annotation invalid I do not see a problem with doing this.

     
  • Chris Myers

    Chris Myers - 2012-05-24

    I am accepting this issue as valid.

     
  • Lucian Smith

    Lucian Smith - 2012-05-24

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

     
  • Nicolas Le Novère

    That should be part of the move to vCard 3, like we did for the omex archive. The issue is more complex than adding an element for middle name.

     
  • Nicolas Le Novère

    I am accepting this issue as valid.

     
  • Nicolas Le Novère

    I meant part of the move to vCard 4. We are already using vCard 3.

     
  • Lucian Smith

    Lucian Smith - 2014-04-04
    • labels: Level 2 Version 4 --> Level 3 Version 1 Core, Level 2 Version 4
    • Group: --> Accept-conformance-implications
     
  • Nicolas Le Novère

    Just a note to add on my comment of 2012-12-21. There were further developments on the front of vCard. In the past, the XML versions of vCard struggled to keep track of the text version that was very underspecified.
    The W3C now developed a proper ontology
    http://www.w3.org/TR/vcard-rdf/
    This is what we advocate in OMEX (although we do not impose any particular vocabulary for metadata).
    Note that there is no "middle" in vCard. The common usage is to use full name rather than first/middle/last which does not cope well with all name forms (e.g. "von" "III" and multiple "middle" names with different importance)
    Relaxing is the way.

     
    • Michael Hucka

      Michael Hucka - 2014-04-04

      This is an unfortunate development, IMHO, because it is significantly different from the structures that we defined in SBML and implemented in libSBML.

       
  • Michael Hucka

    Michael Hucka - 2014-04-04

    I accept this issue as valid.

     
  • Lucian Smith

    Lucian Smith - 2014-04-04
    • Group: Accept-conformance-implications --> Reported-Proposed
     
  • Michael Hucka

    Michael Hucka - 2014-04-04

    I forgot to indicate:
    I accept this issue as valid.

     
  • Frank Bergmann

    Frank Bergmann - 2014-04-07

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

    It would be best if we could get away with allowing multiple vcard versions where the spec is concerned. This will only work of our libraries can take care of this, and pass on what the users want to provide.

     
  • Frank Bergmann

    Frank Bergmann - 2014-04-19

    I am accepting this issue as valid.

    I would change the L2V5 spec, and formulate it in a way to allow any valid vcard 4. As for the rdf one, we can talk about it ... if we restrict it to the rdf/xml part, i could see it work.But I would want us to have some time to overhaul the libSBML implementation, so that it could provide access to the individual vcard elements.

     
  • Nicolas Le Novère

    for "vCard:middle" (which does not exist)
    I disagree with this solution and think no change should be made

    For the whole extension of model history in L2V5
    I disagree with this solution and think no change should be made

    For L3V2, we need a discussion on the whole usage of vCard.

    The change would be like the one that took place between L2V1 and L2V2. It is significant.

     
    • Michael Hucka

      Michael Hucka - 2014-06-04

      About the magnitude of the change: I think it would be very undesirable to cause a large change here. Is there a way to have a minimal change? Or at worst, something along the lines of a small change to the explicit rules currently in L3v1, with the addition of something like "alternatively, you can use all of vcard version X"?

       
  • Lucian Smith

    Lucian Smith - 2014-06-27

    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, 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 expert 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.

     
  • Lucian Smith

    Lucian Smith - 2014-06-27
    • status: open --> closed
    • Group: Reported-Proposed --> Closed - Duplicate
     
  • Lucian Smith

    Lucian Smith - 2014-06-27

    In the interest of making this discussion easier to follow, I am going to close this issue as a duplicate of https://sourceforge.net/p/sbml/sbml-specifications/225/, and point people over there for further discussion.

     

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

Sign up for the SourceForge newsletter:





No, thanks