added Turtle serializations of ontology docs

[baskaufs]

I've converted the TaxonConcept and TaxonName parts of the TDWG ontology into turtle

[nielsklazenga]

Thanks Steve. That will save me a lot of work (I agreed to turn TCS into Markdown).

[frmichel]

So much more readable than OWL/XML! Thx for this Steve ;)

[mdoering]

should we remove the deprecated properties for a discussion basis?

[nielsklazenga]

I think it is best to leave this in for now, as TCS has rank under both TaxonName and TaxonConcept as well. I think the wrong one was deprecated.

[frmichel]

Dear all, I have a question that probably goes beyond this PR, but I'm not sure where to ask it.

TaxonConcept#hasName is an object property linking a taxon concept to its accepted name. It's domain is TaxonConcept. In TAXREF-LD, we'd like to use/extend TaxonConcept#hasName, unfortunately TAXREF-LD's taxa are modelled as classes, not instances. Hence, using TaxonConcept#hasName would entail that taxa are also instances of TaxonConcept, which is a bad practice...
As a consequence, we've extended dwc:scientificName, which is preferably used with a literal object, but still does not impose any domain nor range.

This is by the way a general comment about using domain and range in properties' definitions: this can help in reasoning, but also somehow hampers their reusability. Any idea about whether such domain/range constraints may be dropped to improve reusability?

Franck.

[mdoering]

@frmichel I do not know that answer, but your question raises an important point I wanted to touch on for some time.

I am concerned that we discuss the TCS model already in its OWL incarnation. There are serious issues and differences in technological implementations of a domain model, especially how relations are expressed and literals vs URIs in RDF specifically. It is obviously important for an ontology to discuss this and the creation of the dwciri namespace has been a solution to some of these problems with the RDF agnostic DwC that would have been redundant if DwC would have been designed differently. But at the same time we will have to use TCS in non RDF implementations and will face similar, reverse issues when transferring RDF thinking into CSVs for example.

If have to say I do not know all details of the current TDWG Standards Documentation Standard. Do we need to discuss in what format we want to define an updated TCS? Is OWL, UML or just plain list of terms our preference or is this not an issue at all?

[baskaufs]

Here are a couple things to take into consideration.

The TDWG Ontology (including the TaxonConcept and TaxonName pieces) has NO official standing in TDWG. It was a project that basically one person (Roger Hyam) worked on, but it never achieved any standard status. So it's fine to look at for reference because it provides some draft definitions and refers to specific places in TCS that might be hard to parse out from the XML schema, but that's all.

The other thing is that the Standards Documentation Specification makes it clear that by default, TDWG vocabularies come without any added semantics that have entailments (see Section 4.4.2.2). This means that they are not encumbered with the kinds of nasty semantics that @frmichel has identified. I think this answers @mdoering's question as well. When TCS 2.0 comes into being, it will be born as a basic "bag of terms" that contains pretty much only a definition, a URI, and a preferred label in English. IF the working group decides that they want to layer semantics on top of that basic "bag of terms", then they MUST do so in a separate layer that can be ignored by people who only care about the basic terms (e.g. spreadsheet users).

They should also justify specifically what those semantics accomplish and show that they are needed. This is a requirement for complex additions to a vocabulary (see Section 4 of the Vocabulary Maintenance Specification), although technically it isn't a requirement for a new vocabulary since the scope of the VMS is maintenance of vocabularies, not their creation. Nevertheless, this is a best practice of our peer standards organization and we should follow it as well.

So the short answer to this is: TCS 2.0 will only be a basic bag of terms without formal semantics unless the task group shows that they are needed. I think that I'm technically the TAG's representative to the group and I'll make sure that we do this according to the specifications I mentioned.

[mdoering]

Thanks @baskaufs that helps a lot. Is there any recommendation how to best handle relations with a bag of terms? Are terms like dwc:parentNameUsageID a good design in your opinion?

[baskaufs]

There are a couple different models that could be used to handle relations. I would prefer to avoid the "ID terms" approach because of the problems it causes described in Section 2.6 of the DwC RDF Guide. The simplest approach would be to just create an object property that could be used to link the subject TNU with the parent. That would be the most straightforward from the perspective of possible future Linked Data uses but it could also just be used in spreadsheets if it were populated with a URI. The more complicated approach would be to instantiate a relationship instance that specifies the child and parent TNUs as properties of the relationship. That's pretty much the way the TaxonConcept ontology set it up if I'm remembering correctly. It's more complicated, but it has the advantage of making it possible to say things about the relationship, such as who asserted it, and where.

This is a design choice that the Task Group should address after it specifies the use cases it hopes to satisfy. TDWG has developed a really bad habit of deciding how things should be done and then later figure out how to use those things. That's backwards. We should be figuring out what we want the things to do first, then design them so that they do what we want. That principle applies in this situation.

[frmichel]

Thx @baskaufs for "historical" perspective that I definitely lack.

When TCS 2.0 comes into being, it will be born as a basic "bag of terms" that contains pretty much only a definition, a URI, and a preferred label in English.

I'm fine with that. As I understand it indeed, TCS defines terms but does not make any assumption with respect to how these terms should be implemented/represented using a certain format or technology. The question about OWL properties having domain/range is a choice that should solely concern the OWL representation in light of expected use cases. Unless, as you underlined, the group decides that a term is attached a specific semantics.

The simplest approach would be to just create an object property that could be used to link the subject TNU with the parent.

I must admit I'm still grappling with the distinction between a TC and TNU, although I've carefully (and somehow painfully) read thread #1. In TAXREF-LD, a taxon (I should probably say a taxon concept instead) is an OWL class and is related to name objects (accepted or synonyms) which are instances of both the SKOS Concept and TaxonName#TaxonName classes. This is way, I guess, of depicting TNUs. Am I still missing subtleties?

The more complicated approach would be to instantiate a relationship instance that specifies the child and parent TNUs as properties of the relationship. (...) has the advantage of making it possible to say things about the relationship, such as who asserted it, and where.

This approach would certainly be useful: this would rely on the reification process to assert facts about TNUs. Ideally, I'd love to see TDWG ontologies be usable in both approaches, which is somehow the case I think. Taxonomic registries that simply want to publish a current taxonomic vision would use the simple approach, while taxonomists would use the more complex approach to track down changes and e.g. align two subsequent versions of the same taxonomy.

From my Semantic Web-guy standpoint, DwC RDF terms (including dwciri extension and Dwc-SW) still suffer issues such as the ID terms that you mentioned. Plus, they hardly distinguish names and taxa (which is "insane" if I get the whole discussion in #1). Hence the difficulties I and others encounter when trying to model taxonomic information as Linked Data.
I feel like the TDWG ontologies had great ideas that are much more in line with the LD goals, despite issues such as the domain/range issue I was mentioning. So, if TCS 2.0. is due to be issued soon, what about considering a work group to update the TDWG ontologies accordingly and address those early issues?

Franck.

[nfranz]

Thanks, @frmichel! Crossing threads now, but, to the extent that we are converging on Taxonomic Concepts sensu TCS being human-made theories, and converging on not representing Taxon in TCS (thereby allowing Taxon to play an important role in the applied biological knowledge domain).. well, then I would suggest what is perhaps another surprising development. That is:

Even though we need a notion of Taxonomic Concept to design and communicate about the TCS (version 2), and a broad working definition (my own is here: https://doi.org/10.1017/S147720000800282X; pages 5-6), I do not think that we need to represent Taxonomic Concept directly as a class or entity in an ontology. I think TCS version 1 got that wrong: https://github.com/tdwg/tcs/blob/master/docs/schema/1.01/tcs_v101_p24.png Theories emerge from multiple lines of evidence (of the kind found in systematic treatments and so on [collections, identifications, talks among experts in conference hallways, etc.]). And we can likely model most of these lines. But I am not sure that we can, or need to, have an entity/class for the theory (Taxonomy Concept) as a whole. Likely all we need is an entity for the Taxonomic Concept Label (TCL): Name AccordingTo Publication. RCC-5 relationships take the form:

TCL1 {==, >, <, ><, !} TCL2

Meaning that they are spatial relationships between two or more labels, which identify/name the corresponding Taxonomic Concepts, which in turn are theories that arguably need no direct representation in TCS or in an ontology. The semantic force of providing biodiversity data integration work is thereby not actually "inside" the theories (= Taxonomic Concepts) under this view, but instead is directly embedded into the RCC-5 relationships. In some sense, the relationships become the brokers of Taxonomic Concept correspondence. Said provocatively, the relationships become the Taxonomic Concepts, to the extent that we are modeling them.

Which would then mean that you could potentially rephrase your question of a difference between a TNU (=> http://lists.tdwg.org/pipermail/tdwg-content/2016-April/003582.html) and a Taxonomic Concept, into one of the difference between a TNU and a Taxonomic Concept Label?

I admit that I am a bit lost here myself? Rich's text is dense for me to follow; and my overwhelming first question is: what special powers might TNUs bring to superior data integration work that taxonomic names, TCLs, and various relationships can not also bring to the table?

[deepreef]

So....
"Theories emerge from multiple lines of evidence (of the kind found in systematic treatments and so on [collections, identifications, talks among experts in conference hallways, etc.]). And we can likely model most of these lines. But I am not sure that we can, or need to, have an entity/class for the theory (Taxonomy Concept) as a whole."

I agree with this, but probably for different reasons than @nfranz. I don't think "theories" of Taxonomic Concepts are part of this discussion. We're talking about assertions of explicit and implied circumscriptions of organisms. The theoretical framework behind why people assert those circumscriptions is not really relevant to this space (TCS 2). Theories of this sort only come into play when we talk about "Taxa" (sensu @nfranz).

"Likely all we need is an entity for the Taxonomic Concept Label (TCL): Name AccordingTo Publication."

Yes! And just to make sure we're all on the same page.... TCL sensu @nfranz is a label applied to a TNU entity sensu @deepreef. TNUs ARE the entities for TCLs. We're talking about the same thing here, right? So we can also say (with exactly the same meaning) that RCC-5 relationships take the form: TNU1 {==, >, <, ><, !} TNU2.

Right?

Just to nail this home (and make sure we're not cross-talking):
A TNU is an instance of a Name-Reference (or maybe more precisely, a Protonym-Reference), and a TCL is a convention for applying a human-friendly text-string label to a TNU (each TNU would also have a machine-friendly identifier ... say a UUID ... permanently branded to it as well to keep the machines happy).

Is any of what I just wrote above dissonant? If not, we may be inching towards convergence on these terms. But if so, then we probably have some more long and obtuse posts to write...

"Meaning that they are spatial relationships between two or more labels, which identify/name the corresponding Taxonomic Concepts, which in turn are theories that arguably need no direct representation in TCS or in an ontology."

So....
A Taxonomic Concept (TC) is an asserted/implied circumscription of organisms.
Each TC is represented by a Taxonomic Name Usage (TNU), which is a Protonym-Reference.
Each TNU is labelled with a human-friendly TCL,

If we can converge on this, then I think @nfranz and I are saying essentially the same thing -- that we don't really need to define instances of TCs with their own persistent identifiers (in order to bundle congruent TNUs) -- instead we can simply represent RCC-5 relationships among TNUs (including "==" relationships), consumable by machine reasoning via persistent identifiers (like UUIDs) and labelled for human consumption with TCLs.

But judging by the last two paragraphs of the Nico's post, my hope is that we're simply in violent agreement, but don't quite realize it because we are using terms without a common understanding of their meaning.

Oh, and dude... you're saying that my text is dense? Have you ever read one of your papers? :-)

Seriously, though... I don't think it's so much an issue of how you write or how I write -- it's an issue that this stuff is really hard to articulate with a soup of terms that have multiple and ambiguous meanings.

So, in answer to your last question: TNUs are the objects that TCLs label, so it sounds a lot like we are arguing exactly the same thing, but using different words and different forms of dense text... :-)

[nfranz]

Great, thanks @deepreef. I'd have to agree on my papers. And also otherwise! We can probably largely synonymize TCL and TNU, at least for one of the human/machine audiences. That was actually what I was hoping for but did not dare say outright. I'm fine, going forward, with mostly just using one of the two terms, either Taxonomic Name Usage (TNU) or Taxonomic Concept Label (TCL).

[deepreef]

Wonderful! I think both terms are useful, in that a taxonomicNameUsage represents the entity (name-reference), and a taxonomicConceptLabel is the text-string that can be applied to the entity, following a prescribed format. We should make use of both terms in TCS. The relationship is analogous to the relationship between a protonym (name entity) and a taxonomicName (formatted or verbatim text-string label applied to the entity).

[nfranz]

Fine here, for what it's worth. I am a little concerned that the protonym/taxonomicName distinction does not matter much in terms of data integration function. Either way, one more item that I can see on our radar. How do Taxonomic Names fit into the TCS, functionally? Well, because Taxonomic Names (can => TNUs; do => TCLs) participate in multiple Taxonomic Concept Labels, they are in effect identifiers for sets or bundles or lineages of Taxonomic Concept Labels. And that is an important function.

So, in the framework of the TCS, the following phrase is perfectly functional.

"The history of [Taxonomic Name = Taxonomic Concept Label set identifier] Minyomerus Horn, 1876 is complex enough to warrant a brief review here".

The author is deliberately using a Taxonomic Name which identifies a historically comprehensive but also open-ended set of Taxonomic Concept Labels, ranging from 1876 to the present and likely beyond, without wanting or being able to list each. Productive ambiguity..stage setting for a subsequent more parsed out section that can utilize specific TCLs.

Nomenclatural relationships such as synonymy can thereby seen within the TCS as Taxonomic Concept Label set connectors, although typically a good amount of contextual information would be needed - who established the synonymy between which TCLs and in what way? - to understand which members of each set are nomenclaturally related, in particular.

I seem to recall that the 2005 TCS called Taxonomic Names without an AccordingTo + Publication "Nominal Concepts". I suggest we do not propagate that term; I find that it is almost purposefully deceptive. The TCS can and should handle Taxonomic Names just fine, and indeed they are needed because very often biological publications have passages or instances where they cannot provide or cannot work productively with Taxonomic Concept Label-like referential precision.

[ghwhitbread]

Am I imagining that this is starting to look like the definitions in the Names Workshop document (https://github.com/tdwg/tnc/blob/master/TDWG2018/README.md#terminology) that started the (#1) thread? Also: It is not so good that this discussion has moved out of Issue#1 and into the conversation around @baskaufs pull request!

[deepreef]

OK, cool!

"I am a little concerned that the protonym/taxonomicName distinction does not matter much in terms of data integration function."

Well, actually this distinction is key to data integration function, because it's necessary to disambiguate homonyms, anchor alternate spellings and combinations to each other, define type-specimen-level circmscription boundaries implied by particular TNUs, and a bunch of other stuff. It turns out that Protonyms are actually the key to doing magical things with both nomenclatural and taxonomic data (who knew?), so it's critical not to conflate the text-string label (taxonomicName) with the abstract "name entity" the label is applied to. Sort of like how TNUs are the entity, and TCLs are the label applied to the entity. The main difference is that parity between TNU and TCL is solidly 1:1, whereas parity between Protonym and taxonomicName is M:M.

I realize that most of the above falls into the "dense" category, but this is not the place to go into the subtleties of the data integration function of Protonyms and taxononicNames.

As for the remainder of your post, I'll have to digest it a bit more before I understand what you're trying to say. I suspect in the end we'll find, once again, that we're saying the same thing using different words and different meanings of the same or similar words.

Yes, the notion of a "Nominal Concept" was, I believe, intended to represent a Name without a "sec". I thought the idea was potentially useful, but I've never seen the actual utility of it.

[deepreef]

Oops! I just saw the post from @ghwhitbread. Sorry -- I didn't notice that we had swapped issues. Can these posts be ported over to the original open-ended issue?

[nfranz]

Thanks again, @deepreef. Sorry, but I may need an actual example to see why:

• Disambiguating homonyms;

• Anchoring alternate spellings and combinations;

• Defining type specimen-level circumscription boundaries;

• etc.

  cannot be handled with the syntax TCL1 [relationship] TCL2 (here exemplified):
  Thylacites microps Say, 1831: 9 sec. Say (1831) [insert relevant relationship] Minyomerus innocuus Horn, 1876: 18 sec. Horn (1876).

  Are you saying that protonyms can only be handled as TNUs and not TCLs? Why? I may need to see an example to follow.

[deepreef]

If the extant data always included as much precise information as TCLs require (and the examples you gave), then we'd be in a much better position to pretend that text-string labels (without being anchored to well-defined abstract entities) can solve all of our needs. But the vast, vast, vast majority of extant digital data (GBIF, BHL, etc.) comes more in the form of "Thylacites microps" or "T. microps" or "Thalacites microps", or, if we're lucky, "Thylacites microps Say". Designing an information standard to accommodate the future Utopian world where all biodiversity data is exposed electronically tagged with full TCLs is easy. But we have two challenges: 1) somehow convince producers of biodiversity data to consistently an without typographical error label their data with fill TCLs; and 2) Integrating the existing data (not just the already digital stuff, but also the paper-based stuff that is yet-to-be-digitized).

The role of TNUs (including Protonyms, which are a subset) is to make it much easier to overcome both of these challenges. I would be happy to spell all this out in more detail, using examples of homonym disambiguation and alternate spellings and combinations and defining type specimen-level circumscription boundaries (etc.), but I don't think this is the right issue in GitHub to go into such detail. Perhaps someone more fluent in GutHubese can create a new and appropriate issue to reconcile the notions of TCs, TCLs, TNUs, Protonyms, we can get down into the weeds on this stuff (especially as it relates to TCS 2.0)?

[jgerbracht]

@deepreef "reconcile the notions of TCs, TCLs, TNUs, Protonyms, we can get down into the weeds on this stuff (especially as it relates to TCS 2.0)?" I think this is still the key, i.e. we can't really make any progress, (or I can't at least), until we reconcile these notions. For example, it seems to me that we are still conflating Taxon Concept with Names. For example, is a TCL truly a Taxon Concept Label, or is it more accurate to say it is a TNU Label.

[rdmpage]

@jgerbracht do these things need to be exclusive? Maybe we can reframe this in terms of what is being linked to. For example, on http://www.birds.cornell.edu/clementschecklist/updates-corrections-2018/ the name "Radjah radjah" appears, let's imagine that we want to enhance this page by linking "Radjah radjah" to something:

• We could treat "Radjah radjah" as a text string and link to, say, Google https://google.com/search?q=Radjah+radjah
• We can link "Radjah radjah" to a name, e.g. urn:lsid:organismnames.com:name:5258023
• We can link "Radjah radjah" to a taxon concept, e.g. radshe1.

So, whether it's a "TNU" or "TCL" or whatever is in effect determined by the thing you chose to link too. The same text string can be linked to more than one thing (e.g., we could link to both the name urn:lsid:organismnames.com:name:5258023 and the concept radshe1), and some links will imply other links (concepts have names, so you are implicitly linking to one or more names when you link to a concept, names have text strings, so linking to names implicitly links to text strings).

Rather than conflating things, it seems that we can simply have more than one interpretation of what "Radjah radjah" represents, and if we're the ones making the link, we can determine what kind of thing we link it too.

[nfranz]

@deepreef. Thanks again. I am fine with working this out in a separate thread. In the meantime, I am going to suggest that TNU and TCL could be fully synonymized if we all accepted the following, which in fact I believe right now we do not.

Just as it is unproductive to provide necessary and sufficient conditions for Taxonomic Concept, it is unproductive to provide specific necessary and sufficient conditions for Taxonomic Concept Label and/or Taxonomic Name Usage, jointly or to separate one from the other. Why? Because doing so means overburdening our definitions beyond their basic and productive functions - i.e., to facilitate good practice (but at the cost of allowing so-so practice) - to the point where it is now also the work of the definitions to demarcate, or define, and ultimately perhaps enforce, good practice. I believe (though could be very wrong) it is fair to say that @deepreef wants the definitions to do some of that work of separating (1) something that a particular person can properly interpret under special circumstances (=> TCL..only so-so in all cases), from (2) something that is so consistently structured and detailed as to be reliably and globally machine-resolvable, in any/all contexts (=> TNU..).

And my plea is that, even though I am very sympathetic to the urge to lift ourselves out of the syntactic mud and achieve and more consistently enforce globally unique, machine-interpretable "Taxonomic Names AccordingTo Publication" sets; I feel that definitions are not the right place where that lifting and enforcing can be had, productively, and "upfront" so to speak. For one, I think we will argue endlessly over what are necessary and sufficient conditions for something to be not just this (e.g., a TCL) but also that (e.g., a TNU), in part because this devolves into discussions about relevant informational contexts, certainly at the human level but also at the machine level. "How much detail exactly is enough?" - in the context of taxonomic name renderings and reference renderings - well, good luck.

If the goal is (and it should be) to stimulate good practice, I strongly suggest to isolate definitions from that goal, and pursue it outside of them. Via examples, implementations, recommendations, and even gate keeping. Not: definitions. They are hard to defend universally, in part because the subject matter is very context-sensitive, and they do nothing that cannot be done as or more effectively by practical implementation and leading by example.

"This TCL (or TNU -- whichever term we end up preferring) is an example of great, standard compliant syntax and comprehensiveness. This one here a bit less so. That one is a mess. We love 1, tolerate 2, and reject 3 for our service". That is the important work best done by particular implementations of the TCS, but not well done by the (thereby overburdened) definitions of terms that the TCS entails.

[deepreef]

@jgerbracht: OK, where is the best space for having that specific conversation? On this particular issue thread? Or somewhere else? I don't think it's really a use-case thing -- we just need to hammer out some details. Very briefly: A TNU is the data object that joins a Protonym and a Reference (= Name + accordingTo). I interpret a TCL as a literal string label for a TNU. Whether or not a a TC is a TNU, or is something that needs to be defined differently (i.e., an object representing an aggregate set of TNUs asserted to be congruent in circumscription) remains to be seen. I would suggest we start with defining TNU and its core properties, which would include TCL, Reference, Protonym, and a few other things. Then decide whether a Taxonomic Concept is simply a subset of TNUs, or needs to be something else.

@rdmpage: "Radjah radjah" is a string of characters. It only represents a scientific name in context, and even then, it can be interpreted either as a name name-string (a Binominal representing a species), or as two name objects (one genus name-object combine with one species name-object). It is neither a TNU nor a TCL, because there is no "sec" context.

@nfranz: I don't think it is wise to "synonymize" TCL and TNU. If I understand you correctly, a TCL is a text string formatted according to an agreed-upon formula, representing human-friendly essential components of a TNU (the name part and the sec part). A TNU is an abstract data object with implied core properties, including a unique identifier, a link to a Reference object, a link to three separate TNUs (Protonym, Valid Usage, Parent Usage, the first two of which may be self-referential), and a few key properties (e.g., rank, spelling, and a few other things).

"Nico Franz" is the text string label that is consistently applied to the human being who was born on a certain day and continues to live and contribute to these discussions is the person (abstract object). The human and the literal text string of the label are not the same thing. The text string only has a few properties (e.g., the literal sequence of characters, the digital encoding of those characters -- e.g., UTF-8). The person has many more properties (birth date, etc.). If only one person had the name "Nico Franz", and if that person never changed his/her name (ever), and always spelled it the same way, and never used abbreviations or middle initials or any other variants, then we probably could get away with not distinguishing the person from the person's name. However, if we want to model humans and their names more robustly, we need to consider the abstract "person" object separately from (one of) its name(s) (i.e., the label for the object). All of this is a very good metaphor for the relationship between a TNU (analagous to the person object) and a TCL (analagous to the name "Nico Franz").

[deepreef]

Just to clarify, I don't feel comfortable saying that TCLs and TNUs are "synonymous" for the same reason that I don't think the literal text string "Nico Franz" and the human who wrote the post to which I am replying are "synonymous". One is a text string, and one is a bag of cells and tissue. However, I think @nfranz and I do agree in the sense that they are not separate objects with their own separate sets of properties that need to have subtly different definitions. Rather, I think it makes most sense to define a TNU as the "thing", and the TCL as one of the key properties of that "thing".

[rdmpage]

@deepreef You wrote:

@rdmpage: "Radjah radjah" is a string of characters. It only represents a scientific name in context, and even then, it can be interpreted either as a name name-string (a Binominal representing a species), or as two name objects (one genus name-object combine with one species name-object). It is neither a TNU nor a TCL, because there is no "sec" context.

I think this glosses over my point about links - I’d argue that the links are the “sec” context you say is missing. Linking to something that is explicitly typed makes it clear how something is to be interpreted.

I’d suggest that my example of “Radjah radjah” is sort of what @nfranz is suggesting:

"This TCL (or TNU -- whichever term we end up preferring) is an example of great, standard compliant syntax and comprehensiveness. This one here a bit less so. That one is a mess. We love 1, tolerate 2, and reject 3 for our service". That is the important work best done by particular implementations of the TCS, but not well done by the (thereby overburdened) definitions of terms that the TCS entails.

Linking to an explicit concept (e.g., a node in a tree) makes it pretty clear how an author or reader interprets that name, linking to a name database (e.g., IPNI, ION) may be less precise but potentially gives us a way to compute the set of possible meanings, treating as a text string is even less precise but at least it has been flagged as a name, etc. So perhaps what we should be thinking about are ways to create and describe those links, and how to provide and/or characterise suitable targets for those links, depending on what the people/machines doing the linking want to achieve.

[deepreef]

OK, if the links are the "sec" context, then the link is the TNU. A TNU is simply a paring of a name-thing and a reference-thing, yielding a Name sec Ref instance. The reason we treat it as a distinct object, with it's own persistent identifier, is because there are a few other properties we have found extremely useful for hanging on these Name sec Ref instances.

There are, of course, other links that are important to track (and perhaps assign persistent identifiers to, etc.). But I think you and I are in full agreement that "we should be thinking about are ways to create and describe those links, and how to provide and/or characterise suitable targets for those links, depending on what the people/machines doing the linking want to achieve."

TNUs (labelled with TCLs), which are instances of name-sec-ref, are probably the most powerful, functional and straightforward of these links, because the represent the basis for all nomenclatural stuff and all taxonomic stuff (including taxon concept assertions, synonymies, classifications, determinations, spelling variants, and a whole bunch of other cool and useful stuff).

So maybe we really area all trying to say the same thing using different words?

[jgerbracht]

Maybe we are all saying the same things. I'm still struggling with two items though. One is simply the words we use. " A TNU is the data object that joins a Protonym and a Reference (= Name + accordingTo). I interpret a TCL as a literal string label for a TNU. " I agree with this, it makes sense to me except I think it muddies our communication to call the literal string label for a TNU, a TCL, it's not a TCL, it's a TNU label. It may appear to be a small matter but I would reserve a TCL for a literal string label for a TC. This may lead into the second item I'm struggling with, using a 'link' to describe the context. I'm hoping one of you can straighten this out. I'll toss out an example of this. 'Dog', it conjures up in our minds all the existing entities that are members of the Taxonomic Concept labeled 'C. familiaris'. If however, a link is needed to determine the actual context, 'Dog' may mean different things to different individuals (includes or excludes Wolves for example), making it more difficult for humans and computers to communicate reliably. One would need to communicate 'Dog' + Canis familiaris + 'sec'. It still seems like we need a label for 'Dog' which we recognize is fuzzy (sorry ;) I think we also want a TNU (with a label of ) Domestic Dog, Canis familiaris 1758 Linnaeus. Again, maybe I've not grokked how a 'link' fits into this. I guess when I think of 'link', I think that a user (human or computer) will need to go somewhere else to determine whether the text string they see refers to Dog or to Canis familiaris 1758 Linnaeus.

[rdmpage]

@jgerbracht Links are a way to make a reference to something concrete, especially if the thing we link to comes with some information that describes what kind of thing it is.

Put another way, I think a link to a Wikipedia entry, e.g. Dog is a reasonable way to say "dog" in a fuzzy sense, although the page itself is pretty precise. Alternatively, the link could be to a dictionary, or even a Google Search. In each case we're linking to a web site or a search, which would be one way of saying "we're not sure what this means, here is a link that points to alternative meanings".

More precise meanings (such as a particular taxonomic name or taxonomy) could be linked to directly. If those things being linked to are able to describe themselves (i.e., a computer can fetch the link and ask what type of thing it is) then you have a mechanism where the meaning of the link is explicit.