David Nickerson wrote: > Andrew Miller wrote: > >> David Nickerson wrote: >> >>> I'm wondering if there needs to be some kind of formal progression of >>> metadata standards being adopted by the CellML project. While I concede >>> that it was rather arbitrary to add the simulation and graphing >>> specifications under the CellML metadata umbrella, I can see how those >>> two are going to play very important roles in the future of CellML. I am >>> less certain of the value of the Custom Subset specification. >>> >>> I guess the question is whether we are happy to continue simply adding >>> any and all metadata specifications that people come up with under the >>> CellML metadata umbrella? or whether we want to implement a system >>> whereby draft specifications are first circulated on this mailing list >>> and require a certain level of support (or maybe a lack of objections?) >>> before the CellML project formally accepts the draft for further >>> development under the CellML metadata umbrella? >>> >>> >> All three specifications are merely drafts, and they have not been >> accepted in any sense. The drafts are put on the cellml.org site simply >> because that is the most appropriate place for them to be stored, but >> this does not imply that they are in any way endorsed by the CellML team >> as a whole. >> > > To me, having the draft available under > http://www.cellml.org/specifications/specifications and using a > cellml.org namespace indicates that the CellML Project has accepted the > draft as a valid specification to be developed under the CellML Project. > It wouldn't make sense to use a different namespace for the draft, and then change the namespace, because that would mean that experimental implementations would all have to be changed (we shouldn't be making substantive changes between agreeing on a draft and releasing an endorsed specification, and changing the namespace is a very major change in terms of compatibility).
Having specifications in the URL is appropriate for a draft specification. The only time this would be a problem would be if a draft purported to be endorsed by the CellML team when it was not (all drafts at the moment have language which makes it explicitly clear that they are drafts, and are not yet endorsed). > I'm just worried that we are going about things in a rather backward > manner where we put up metadata specifications and then discuss whether > they are valid or not. > This is the usual way of developing standards: 1) Someone writes a draft. 2) The community identifies problems with the draft. 3) Any problems are fixed, and step 2 is repeated until the draft is of good quality. 4) The specification gets endorsed by the group standardising the specification. > >> Any CellML-specific information which could potentially be used by more >> than one tool should be stored in a format which is publicly documented, >> and so Custom Subset, and any other specifications which people might >> propose, should be stored somewhere (although if someone submitted a >> draft which conflicted with some other work, e.g. which stored the same >> information in an incompatible way, we could put a CellML team note on >> the draft, discouraging its use). >> > > in your example that just seems wrong - we could end up with a whole > bunch of conflicting specifications and all we do is suggest people > don't use them? We can't stop people writing specifications which conflict with existing specifications (after all, our mailing lists aren't moderated, and they could still put the specification up on a site under their own control). We therefore have two choices in such a case: 1) Have the specification up on the cellml.org website, together with a comment on why the CellML team recommends that the specification not be used, and accompanied by a pointer to an alternative specification. 2) Just ignore the specification. Implementers are likely to find the specification elsewhere (e.g. in the mailing list archives, or on the specification designer's site), and, not knowing that there is a better way endorsed by the CellML team, implement the new specification. I think we are much better to acknowledge the existence of flawed specifications (whether they are unnecessary as they duplicate existing work, are not as backwards comaptible as they could be, have technical problems, are ambiguous, or any other specification problem), but make recommendations to implementors who see the document about why the document should not be used as is. Also remember that RDF is designed to be extensible, so there is no problem with specifications for highly domain specific data being there. There is certainly no requirement that all metadata specifications get supported by any particular tool. That said, it is important that competing metadata specifications, each of which store the same information in incompatible ways, do no arise, because this reduces the interoperability of tools (RDF makes it easy to extend existing specifications, rather than write a new one, so there is seldom reason to do this, except when vendors are unaware of each other's work, or vendors deliberately try to break compatibility for political reasons). By providing a centralised repository of metadata specifications, the CellML project can help to reduce the number of alternative ways in which the same data is stored, and therefore allow tools to inter-operate better. > There has to be a mechanism whereby the specifications > are filtered before they are added to the CellML specifications section. > There is no reason for people not to develop and discuss early versions > of a draft specification using the cellml.org wiki (or any other > collaborative tool they may choose) and then once a suitably complete > description of what the draft specification hopes to achieve has been > established it can be sent to the cellml-discussion list to see if it > has enough support to be added to the CellML Project's list of > specifications. > We still need a list of specifications, including a list of specifications which are still in draft, so those wiki pages can be found. I think that the current page does make it clear which drafts are endorsed and which are under development, although maybe we could separate the two types of draft more (e.g. listing them on different pages). > Obviously this isn't going to be a huge problem as I don't imagine we > will be overwhelmed with draft specifications - but just for the sake of > long term stability I think we need to consider such processes now > before any problems come up. > I don't foresee how having many specifications up there can cause problems, but if any problems do arise, there is no reason why we can't adopt a different policy later. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
