Ann,
I agree that the repository should support this by providing the
necessary infrastructure. Requirement (5) is supposed to enforce the
usage of the infrastructure, with other words it is intended to express:
"Don't change your ontology and upload it into the repository without
making it a new version!". Which is common sense, of course, but since
the OBO Foundry found it necessary to include a rule like that I guess
that they encountered a situation where some people did not follow this
rule. If you think it is too trivial, I'll remove it. (01)
I agree that we need to distinguish between originator's version and
repository version in the metadata, and that the repository should be
able to handle forks. (02)
Fabian (03)
Ann Wrightson wrote:
> I agree with the scheme below except that IMO the repository should have a
>simple version structure of its own, and expect mapping of contributed
>artefacts' versioning structure to that model, that is, record originator's
>version alongside the interoperable repository version in the metadata. A
>suitable candidate repository version structure would be linear sequences of
>supersession-versions with the ability to "fork" variants at any point (which
>could themselves have supersession-version chains). Rejoining of variants'
>supersession-version chains is problematic & should not IMO be attempted in
>the repository, though a human-readable note should be allowed to enable
>originators that do support such join-backs of variant
>supersession-version-chains to state it has occurred.
>
> Ann W.
>
> ________________________________
>
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx on behalf of Fabian Neuhaus
> Sent: Thu 3/13/2008 5:21 PM
> To: ontology-summit@xxxxxxxxxxxxxxxx
> Subject: [ontology-summit] [Quality] Gatekeeping proposal
>
>
> Dear All
> I would like to kick off the discussion about Quality and Gatekeeping. The
>Ontology Summit 2008 is only a few weeks away and there is much to do! As the
>title of the discussion thread suggests, we have two tasks: We need to develop
>a set of minimal requirements that any ontology needs to fulfill in order to
>be accepted as part of the Open Ontology Repository (= Gatekeeping). Further,
>we need to discuss the different ways the quality of an ontology within the
>OOR can be evaluated and what kind of services the OOR needs to provide to
>support these kinds of evaluation.
>
> I suggest that we start with the gate keeping discussion: What are the
>minimal criteria that an ontology needs to meet in order to be accepted as
>part of the OOR? I would suggest to set the bar rather low and only focus on
>criteria that ensure that it will be easy for the community to use the
>ontology as resource.
>
> Here is a list of requirements that would do that (some of these principles
>are adopted from the OBO Foundry):
>
> 1. The ontology is open and available to be used under the Creative Commons
>Attribution license without any constraint other than (a) its origin must be
>acknowledged and (b) it is not to be altered and subsequently redistributed
>under the original name.
>
>
> This criterion is a specification of what "open" in "Open Ontology
>Repository" means.
>
>
> 2. The ontology is expressed in a formal language with a well-defined syntax.
>
> Obviously, an ontology is going to be more valuable to a large audience if it
>is expressed in a widely used formal language, but the repository is not
>restricted to those. The authors are required to provide a reference to a
>document that specifies a grammar of the formal language.
>
> 3. The authors of the ontology provide the required metadata.
>
> Pat Hayes and Michael Gruninger are championing a discussion about the
>ontology of ontologies and metadata. This requirement will enforce the use of
>the result of this discussion since it ensures that no ontology can be
>submitted without providing the necessary metadata. The goal is to enable
>users to quickly survey the available ontologies and find the right ones for
>them.
>
> 4. The ontology has a clearly specified and clearly delineated scope.
>
> The specification of the scope is strictly speaking part of the metadata but
>important enough to mention it explicitly. It enables potential users to get
>an idea what a given ontology is about without browsing the ontology.
>
>
> 5. The ontology provider has procedures for identifying distinct successive
>versions.
>
>
> I'll post this list also on the QualityAndGatekeeping wiki page:
>http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008_QualityAndGatekeeping
> This page will be updated with summaries of our discussion.
>
>
> Best
> Fabian
>
>
>
>
> ------------------------------------------------------------------------
>
>
> _________________________________________________________________
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2008/
> Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008
> Community Portal: http://ontolog.cim3.net/
> (04)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2008/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008
Community Portal: http://ontolog.cim3.net/ (05)
|