Canonical:
* basic: reduced to the simplest and most significant form possible
without loss of generality; "a basic story line"; "a canonical
syllable pattern"
* canonic: conforming to orthodox or recognized rules; "the drinking
of cocktails was as canonical a rite as the mixing"- Sinclair Lewis
* This term implies that something has been reduced to its simplest
form (note that it also has a different religious meaning).
* In programming, canonical means "according to the rules." And
non-canonical means "not according to the rules." In the early
Christian church, the "canon" was the officially chosen text. In
The New Hacker's Dictionary, Eric Raymond tells us that the word
meant "reed" in its Greek and Latin origin, and a certain length
of reed came to be used as a standard measure. In some knowledge
areas, such as music and literature, the "canon" is the body of
work that everyone studies. The terms are sometimes used to
distinguish whether a programming interface follows a particular
standard or precedent
search for "define:canonical" comes back with these plus a few religious
ones!
What isn't included is
* Cannon shaped c.f. conical.
But that is just my definition :)
Paul Kirk wrote:
> I think I agree with all this. I too, strongly support meaningful
> 'tags' - and NameVerbatim fits my definition of meaningful. NameSimple
> is too vague. And I've now forgotten what 'canonical' means - Google
> got me too bogged down in religion - can someone please enlighten me?
>
> Paul
>
> ------------------------------------------------------------------------
> *From:* tcs-lc-bounces at ecoinformatics.org on behalf of Richard Pyle
> *Sent:* Fri 06/05/2005 12:21
> *To:* tcs-lc at ecoinformatics.org
> *Subject:* Re: [tcs-lc] nameObjects, spellings, vernaculars, etc
>
> > If the NameSimple element of TCS IS intended for verbatim spelling
> > then it needs another name, for clarity.
>
> The history of "NameSimple" in TCS preceeds LC/Christchurch. I'm not sure
> of its original intend, but I suspect it was created without a lot of
> thought to the distinction between "Code-correct" and "verbatim"
> name-strings (no criticism intended -- to be honest, I hadn't thought much
> about it either before we really started discussing LC). In
> Christchurch, I
> think the LC breakout groups sort of assumed it would be a canonical
> concatenation....but that was before "Label" was introduced as a root
> element in LC. I've asked the question a couple of times (what is the
> specific function of NameSimple), and I even re-christened it
> "NameVerbatim"
> in the version of TCS/LC that I sent (it didn't seem to get much
> traction...), to achieve exactly what you are suggesting.
>
> > Otherwise it should be
> > exactly the same as the Label element of LC and be in the canonical
> > form, with another element there for the verbatim or as-published
> > spelling.
>
> Why does there need to be two elements, with different names, in different
> parts of the overall schema, that share exactly the same purpose? One
> could
> argue that it would serve the function of canonical name in cases
> where one
> only has the name, and has not (yet) established a link with a full
> canonical name object. But I would counter that argument with the point
> that, such cases imply that one has not identified the proper canonical
> name, and as such, what else would one have, besides the verbatim name?
>
> That said, I would STRONGLY advocate re-naming to "NameVerbatim", or
> "VerbatimSpelling", or something like that.
>
> > A well designed schema should have element names which 'do
> > exactly what it says on the tin'
>
> Actually, I think "NameSimple" leaves a lot of latitude for
> interpretation.
>
> > - OK - I see your point. As it happens, IPNI will only be recording
> > the first publication of a name, so the number of orthographic
> > variants is limited to the original spelling of the author, plus any
> > corrections (or mistakes) made by IPNI rendering that into canonical
> > form. But other databases of course will record more than the first
> > use of a name. In that case each publication instance can come with
> > only one orthographic variant (unless the author has been
> > inconsistent within the article or book).
>
> There are cases (more than just a rare few) where a single author will use
> more than one spelling in the same publication. Sometimes this is
> clearly a
> lapsus or printer's error, ad can be safely ignored or mentioned in a
> human-readable comment somewhere. At the other extreme are cases
> where the
> author used two different spellings where it's not so obviously a
> lapsus. I
> can give examples, if you're interested. But I don't think this is
> something that needs to shape the structure of LC. I would say it should
> support only one verbatim spelling per AccordingTo publciation/NameObject
> instance.
>
> Also, when you say "original spelling of the author" -- can I safely
> assume
> you mean "original spelling of the scientific name by the original
> author",
> and not "original spelling of the author's name" (e.g., "L." vs.
> "Linnaeus")?
>
> > To me it seems simple (I know you will correct me on this point) -
> > each concept will have one publication instance and hence one
> > orthographic rendering, which may be reproducibly correctable to one
> > canonical form.
>
> No corrections! This is exactly what I feel as well!
>
> > Therefore the LC part of the schema needs to have a
> > place where the (single) 'as published' name goes, plus a place
> > (Label) where the canonical form goes.
>
> In LC, I assume you mean the "as published" name is the verbatim name
> as it
> appeared in the original description/protologue? If so, yes!
>
> > I thought this was in the schema already.
>
> I thought that's what "OriginalOrthography" was for (an element I
> wholeheartedly support, because this is a special-case "Verbatim"
> spelling,
> separate from the concept instance).
>
> > Multiple versions of the same name-object will be
> > mapped onto each other by mapping concepts to concepts, because each
> > version should have a publication-instance of some sort.
>
> Yes, but if Names are treated as stand-alone objects (as in v0.95.5), then
> the multiple verbatim renderings of the same "name" will also be
> cross-linked to each other by virtue of the fact that all of these concept
> instances will point to the same "NameObject" (LC instance). Thus, the
> name-links would exist even without the concept-concept mappings.
>
> > I think Rich and I are in agreement here ...
>
> As do I!! :-)
>
> > as to what consitutes a name object, I leave that to the real
> > taxonomists
>
> So far (as in my previous), it seems to be:
>
> Botany View:
> "GenusOrMonomial Name-Unit [+ species Name-Unit [+ tertiary Name-Unit +
> tertiary Name-Rank]]"
>
> Zoological view:
> "Name-Unit"
>
> Just so everyone is clear, "Name-Unit" is not simply the string of
> characters that form a single component of a scientific name. Rather,
> "Name-Unit" implies a well-defined "object", with multiple inherent
> properties such as the creation event (=protologue), and many/most of the
> elements in LC. It's what I would call a "Protonym".
>
> Any other candidates to define a "NameObject"???
>
> Aloha,
> Rich
>
>
> _______________________________________________
> Tcs-lc mailing list
> Tcs-lc at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Tcs-lc mailing list
>Tcs-lc at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>
>
--
==============================================
Roger Hyam
----------------------------------------------
Biodiversity Informatics
Independent Web Development
----------------------------------------------
http://www.hyam.net roger at hyam.net
----------------------------------------------
2 Janefield Rise, Lauder, TD2 6SP, UK.
T: +44 (0)1578 722782 M: +44 (0)7890 341847
==============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050506/6e88e448/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roger.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050506/6e88e448/roger.vcf