The Mangrove Form Process
DetailsThe table below are an attempt to document discussions between GJR, PH and PA of some developing ideas on the forms and function of the wiki data entry process.
We can see that to capture Taxon Profiles, built with terms defined by taxonomists, the work flow should be adaptable to changes in the process or term definitions, so layering of the form construction was seen as a necessity.
- Term creation requires a form.
- Content Template creation requires a form
- and Content Template completion requires a form
An instance of the Content template creation form is shown copied for each Taxon/Family/Specie The structure of the forms will be as follows:
Term creation form
Label: "eg. Distribution"
Context: (namesspace) Derived from Parent Topic, Parents's Topic as required. The Context or namesspace can be thought of as a separator of meaning, for example the precise definition of the term habitat that a taxonomist wants to express for a plant, will not be the same as the definition when used to describe a bird. Might the definition not reflect this different definition? Yes it will but grouping terms together with a namespace will allow the user to more easily locate the term.
Definition of the term:
State: Verified, In_progress, (deleted?)
DC terms: |
Dictionary type SKOS definition Links are used to describe synonyms of varying degrees of exactness:
Thesaurus type hierarchy relationships are used to indicate relationships with other terms within this or 3rd party Ontologies:
distribution This.template DC:creator (e.g. A Frost) State:Verified, In_progress, (deleted?)
|Content Template Instance State: Verified, In_progress, (deleted?)|
Exemplars of taxon profiles might be any of the following and often include multiple profiles per work, each profile on a different species within a family or higher taxon.
- Shark book
- Birds of Australia the CD
- Birds of Australia the text
- Website on moths of Australia
- Each of these would very likely refer to secondary sources of information whose authors are cited and in addition to the species pages will have input from other contributors who may provide:
- an explanation of the format of contents
- the prologue defining the contents and use of text
- 206 Bird Descriptions
- 600 Factsheets Dublin Core wasn't intended to be used to describe individual parts of texts in the way TRIN is endeavouring to describe them.
Comparing Classes with PropertiesClasses and Properties are defined using various attributes, e.g. Dublin Core have a set (Name, Label, Identifier, Definition and Type)which have been mapped to RDF and RDFS concepts, so when are comparing terms what Attributes should be used in the comparison. One of the issues when mapping terms is to ensure that the definition of each concept is equivalent, but in addition to definition there are other comparators to consider when mapping two terms: Namespace, TypeOfTerm and really any of the linkages provided by the other attributes (BroaderThan?, Refines...). Mapping one concept (TypeOfTerm Class) with another concept (typeOfTerm Property)... ...for more info on The Warwick Framework Architecture click here
TermsTerms have been captured from the various existing Taxon Profiles, e.g. birds and plants. Definitions of these terms will be derived from the associated contents of the extant Taxon Profiles. It's planned that the terms will then be vetted by the Taxon Profile creator ensuring a close match and the intent has been captured as accurately as possible. Each term is then analysed to find associated concepts, and each concept has a topic created for it and linkages are created between the concepts. For example this tracking of the concept of Egg:
[jpg] [ps] [svg] Some of the these concepts/nodes can be considered things with parts, while others are processors which incorporate few or many steps/stages. It may be better to represent some of these nodes as the connections between the other nodes.
[jpg] [svg] -- PaulAlexander - 22 Oct 2009