Chronological Thread 

< Chronological >      < Thread >

---

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] New Draft: Custom Subset Metadata specification, Andrew Miller, 11/06/2006
  • [cellml-discussion] New Draft: Custom Subset Metadata specification, David Nickerson, 11/07/2006
    • [cellml-discussion] New Draft: Custom Subset Metadata specification, Andrew Miller, 11/08/2006
      • [cellml-discussion] New Draft: Custom Subset Metadataspecification, David Nickerson, 11/08/2006
        • [cellml-discussion] New Draft: Custom Subset Metadataspecification, Andrew Miller, 11/08/2006
          • [cellml-discussion] New Draft: CustomSubset Metadataspecification, David Nickerson, 11/08/2006

---

Archive powered by MHonArc 2.6.18.