Class:GeographicOrigin

[mtrekels]

Parent	ObjectGroup
Label	Geographic Origin
Definition	The geographic location from which objects associated with the ObjectGroup were collected.
Usage
Required	No
Repeatable	Yes
Relationships	Range: ObjectGroup | Class-level properties: Reference, Identifier, MeasurementOrFact
Potential standards/vocabularies/ontologies to adopt	Potentially the Getty Thesaurus of Geographic Names.
Notes

[nielsraes]

The geographic location from where objects associated with the CollectionDescription were collected.

[debpaul]

Hi @nielsraes and @pzermoglio.

1. Paula, you are suggesting that definitions for the terms in this class already exist, yes? Thanks for going ahead and putting those definitions in the comments. And as @mswoodburn shared, "We had a chat with @baskaufs about this, and will need to have the same definition, but can use the usage notes to describe them within the context of the CD standard. He took that approach for Audabon Core, I think"
2. To @mswoodburn I'm curious how people will provide more than one Country (see discussion in the Country ticket). Some guidance here might be needed in the explanation of the Country field.
3. This would mean multilple ISO codes too, yes?

[pzermoglio]

@debpaul Yes, if you are reusing terms from Darwin Core, I would expect that definitions would be those in dwc, and that particularities of usage may be described in the notes.
On the other topics...some thoughts:
First thing that comes to mind is: you should not expect more than one value in any of the terms of this class (as for the strict defs in dwc, and expecting controlled values for most of these terms).
I can see that depending on what (or rather the scope of what) one would describe, there may make more or less sense to use the terms in this class as one-to-many relationships. I can imagine that if one was to describe a collection that only has specimens/obs from a particular locality, you would have a single value for each of the fields in the class. No problem there. If instead you were describing a slightly larger collection, lets say that contains specimens from several localities in a given county, locality would need a one-to-many, but not the rest of the terms in the class. Going big, if you wanted to describe a whole museum as a collection, you could potentially need one-to-many for all the terms in the class (several states, several countries, several continents, etc). A single spreadsheet should not deal with this (a- terms expect a single value; and b- one should never have two fields named the same). Flattening all this info would need using extensions similar to what dwc does with extensions. Not undoable. But I wonder what the best practice recommendation would be for this. Would big collections choose to go for just completing higher geography fields if their geographic scope is large? (eg, not use stateProv, county and locality at all if they have specimens from all over a country, and avoid having to use some extension). And further, would it even make sense that they provide all that granularity?
Just thoughts :)

[nielsraes]

Refers to the objects associated with the collection. Meaning that all properties of the class refer to the objects and not the collection itself. E.g. the geographic origin of the South East Asian plant collection of Naturalis (Netherlands) is SEA and not NL.

[mswoodburn]

The dwc definitions of terms within this class often explicitly include the dwc class name ('Location'), which doesn't match the class name that we're using so won't really make sense.

If definitions for dwc terms that we adopt need to be preserved to the letter, then either we need to 1. create new terms instead for CD wherever 'Location' is in the definition (which wouldn't be ideal as it would be pretty much a duplication apart from the class name), or 2. change the CD class name to 'Location' (which we'd also rather avoid, as GeographicOrigin helps to contextualise the class for CD, 'Location' being a bit more generic).

@baskaufs any advice? Have you had to deal with this situation before?

[baskaufs]

More and more I have been thinking that TDWG relies too much on people getting meaning from term names or labels, and not enough on insisting that people look at the term definitions. This particularly gets in the way when terms get borrowed from elsewhere where you have no control over it. I think that you should name you class in a way that makes sense and people should read the definitions and documentation to understand how to use the terms. The term names (i.e. URI abbreviations) are really identifiers and people should not be leaning on them to get an understanding of what terms mean. Just my 2 cents worth.

[Jegelewicz]

I would think that Countries and States would be more useful than continent in a collection description (especially for those that are more specific than "global"). I'm surprised they are not options under this class.