New Term - dcterms:PhysicalResource

[baskaufs]

New term

• Submitter: Steve Baskauf
• Efficacy Justification (why is this term necessary?): At the present time, Darwin Core does not have a top level class term for describing physical entities. The Material Sample Task Group has been working for over a year to sort out the relationships among existing classes of material things in Darwin Core with the goal of addressing shortcomings in our ability to share information about physical things. This task has been hampered by the shortcomings of the current broadest term for material things: dwc:MaterialSample. Because that term requires an aspect of sampling, it conflates the role of the material (to serve as a sample) and the fundamental type of the resource (that it's a material rather than digital or information resource). This complication has hindered the progress of the group, whose work is now at a critical phase with the need to harmonize its work with that of Latimer Core (currently under review). This proposal would improve the situation by importing into Darwin Core a term from what is probably the most well-known metadata vocabulary: Dublin Core. That term has exactly the scope (material things) that is being considered by the Material Sample Task Group and importing it into Darwin Core would allow the group to clarify its work by describing the kinds of material things, rather than material samples.
• Demand Justification (name at least two organizations that independently need this term): Material Sample Task Group, which includes representatives of over 10 organizations, GBIF because this would be a standardized term for the highest level classification in its developing "Grand Unified Model": "Material Entity"
• Stability Justification (what concerns are there that this might affect existing implementations?): This would not prevent the use of any existing classes of material things within Darwin Core. However, it would be understood that it would be a superclass to dwc:MaterialSample, dwc:PreservedSpecimen, dwc:LivingSpecimen, dwc:FossilSpecimen. Since entailment-generating assertions are no longer included in basic "bag-of-term" metadata, these subclass relations would not be asserted directly by subClassOf statements for those other classes, although such assertions could be included in a vocabulary enhancement layered on top of the Darwin Core bag of terms. The relationship of this term to dwc:Organism should be the subject of future discussion.
• Implications for dwciri: namespace (does this change affect a dwciri term version)?: N/A since this is not a property

Proposed attributes of the new term:

• Term name (in lowerCamelCase for properties, UpperCamelCase for classes): dcterms:PhysicalResource
• Organized in Class (e.g., Occurrence, Event, Location, Taxon): N/A, it is a class itself
• Definition of the term (normative): A material thing. (taken verbatim from the DCMI Metadata Terms)
• Usage comments (recommendations regarding content, etc., not normative):
• Examples (not normative): a specimen, material that is destructively sampled, a physical object observed but not collected
• Refines (identifier of the broader term this term refines; normative):
• Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative):
• ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative): none (I think? Don't see any equivalent class in the Unit Type Classes)

[Jegelewicz]

I support this!

The relationship of this term to dwc:Organism should be the subject of future discussion.

For some discussions already in place see https://github.com/tdwg/material-sample/issues/22 https://github.com/tdwg/material-sample/issues/23

The MaterialSample Task Group concluded that an organism may be a MaterialSample, but not all MaterialSamples are organisms. I think we could safely replace MaterialSample with PhysicalResource and say the same thing.

[tucotuco]

I agree with this too, and confirm that dcterms:PhysicalResource is exactly the same as MaterialEntity in the GBIF Unified Model.

One interesting observation that I think is an aside. Darwin Core incorporates dcterms:type, which has a controlled vocabulary that includes dcmi:PhysicalObject, which is NOT the same as a dcterms:PhysicalResource. It is more restrictive because it is defined as "An inanimate, three-dimensional object or substance." This is more restrictive than dcterms:PhysicalResource. It seems an omission in the design of Dublin Core not to support the broader term in its type vocabulary. The class dcmitype:PhysicalObject would clearly not work as a broader term (superclass) for dwc:Organism, as an Organism need not be inanimate. The term dcterms:PhysicalResource does not suffer from this shortcoming and could very well serve as a broader term (superclass) for dwc:Organism. Thus, I think the adoption of this term paves the way to solve a problem we (or at least I) didn't realize even existed. That needs two thumbs up!

On Wed, Nov 23, 2022 at 3:03 PM Teresa Mayfield-Meyer < @.***> wrote:

I support this!

The relationship of this term to dwc:Organism should be the subject of future discussion.

For some discussions already in place see tdwg/material-sample#22 https://github.com/tdwg/material-sample/issues/22 tdwg/material-sample#23 https://github.com/tdwg/material-sample/issues/23

The MaterialSample Task Group concluded that an organism may be a MaterialSample, but not all MaterialSamples are organisms. I think we could safely replace MaterialSample with PhysicalResource and say the same thing.

— Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/421#issuecomment-1325463602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQ727V4MXPZ6O4B53JVV3WJZMATANCNFSM6AAAAAASJEOK5M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[baskaufs]

One interesting observation that I think is an aside. Darwin Core incorporates dcterms:type, which has a controlled vocabulary that includes dcmi:PhysicalObject, which is NOT the same as a dcterms:PhysicalResource.

One thing that came out of the discussion between the Audubon Core 3D Task Group and the DCMI usage board was that using the DCMI type vocabulary as the source of values for dcterms:type is only a suggestion, not a requirement. They pointed out that the comment is "Recommended practice is to use a controlled vocabulary such as the DCMI Type Vocabulary" (my emphasis) and that communities of practice can establish their own controlled vocabularies that they expect to be used. In the past, TDWG has been pretty focused on only using the DCMI type vocabulary, but I think it's time to consider deviating from it. I know that in the case of Audubon Core, it has pretty much been decided to mint a "digital3DResource" class to be used with dcterms:type since none of the existing terms works and the DCMI Usage Board has no intention of adding any type terms.

Another comment relevant to this is that we should consider whether it's actually more appropriate to be using rdf:type rather than dcterms:type. dcterms:type is more well known, but DCMI has actually said that at least in an RDF context, rdf:type is to be preferred over dcterms:type. I'll have to find the reference, but I think it's cited in the Darwin Core RDF Guide somewhere.

[baskaufs]

Another comment relevant to this is that we should consider whether it's actually more appropriate to be using rdf:type rather than dcterms:type. dcterms:type is more well known, but DCMI has actually said that at least in an RDF context, rdf:type is to be preferred over dcterms:type. I'll have to find the reference, but I think it's cited in the Darwin Core RDF Guide somewhere.

It's here

[cboelling]

I support the addition of this element with the scope indicated. The terminological choice of the label "PhysicalResource" is one of a couple of options, including perhaps "MaterialEntity", "PhysicalEntity", "MaterialObject", "PhysicalObject" - see below.

I can confirm that the proposed dcterms:PhysicalResource is, in its generality, exactly what is needed to facilitate export and sharing of representations of object histories from the applications being developed in the DINA consortium.

More importantly, addition of this term will help to close a gap towards a multitude of knowledge representations in the Open Biological and Biomedical Ontologies, a number of which, for a long time already, use the element MaterialEntity as a top-level class. This class was originally defined in the Basic Formal Ontology (BFO).

To foster compatibility I therefore propose to use the label "MaterialEntity" for this new term and updating the definition along the lines of the annotation provided for the corresponding element in BFO.

In comparison to DCMI I find that BFO is the more advanced and conceptually consistent framework to structure knowledge representations, so it might be helpful to take it into consideration here. One example to illustrate this is that DCMI, alongside dcterms:PhysicalResource has dcterms:PhysicalMedium defined as A physical material or carrier. without specifying the relation between these classes.

One note about process: personally, given the work that has been done in the Task Group, and especially the outcomes of the recent working session on Nov 7 2022, I would have preferred if the motion to add this element would have been proposed in the Material Sample Task Group first to mint a joint proposal as a reflection of the contributions to the task group by a number of individuals.

[tucotuco]

Nice summary, @cboelling. The MaterialEntity class in the Unified Model originated in BFO, so there is perfect compatibility there. To ameliorate the source of this proposal, I have added the issue label "Task Group - Material Sample" in an attempt to give credit to its origins. We can move the issue to the Task Group issue tracker if that is more palatable, awaiting a consensus from there on how to move forward with all Material Sample considerations at once. Open to suggestions on that front.

[jbstatgen]

• Because that term requires an aspect of sampling, it conflates the role of the material (to serve as a sample) and the fundamental type of the resource (that it's a material rather than digital or information resource).

Thanks a lot @baskaufs for separating out these two aspects. With this, I feel we have a basis from which to move the next step forward.

A request for clarification: Are bfo:MaterialEntity and dcterms:PhysicalResouces equivalent (exactly the same)?

Checking the definition and editor note for bfo:MaterialEntity and reading its examples, it seems that MaterialEntity includes "energy", eg. examples are "a photon", "a tornado", "an energy wave". Thus, the core concept of MaterialEntity I would associate with "empirical".

What we are talking about in our context, I thought, is rather the "mass" than then "energy" part of "matter" (cp. the bfo:MaterialEntity editor note). dcterms:Physical Resource seems vague on the details - would that mean that it might be more fitting?

My concern is that if we go too far into the "energy" part of matter, then we end up with a continuum between PhysicalResource and "InformationArtifact " as eg. attributes of a term "baseTypeOfCollection" or similar at the object level, because at one point the 0's and 1's of digital information become matter.

However, if bfo:MaterialEntity and dcterms:PhysicalResource are equivalent, then there is no difference between choosing one or the other term; plus the philosophizing about matter and information might be moving too much into splitting hairs.

[cboelling]

A request for clarification: Are bfo:MaterialEntity and dcterms:PhysicalResouces equivalent (exactly the same)?

From the available documentation, I understand that these are meant to be equivalent - although I have little experience in how dcmi:PhysicalResource is practically applied.

Checking the definition and editor note for bfo:MaterialEntity and reading its examples, it seems that MaterialEntity includes "energy", eg. examples are "a photon", "a tornado", "an energy wave". Thus, the core concept of MaterialEntity I would associate with "empirical".

What we are talking about in our context, I thought, is rather the "mass" than then "energy" part of "matter" (cp. the bfo:MaterialEntity editor note). dcterms:Physical Resource seems vague on the details - would that mean that it might be more fitting?

I find some of the examples for instances given for bfo:MaterialEntity in the BFO documentation confusing or even plainly wrong in light of the elucidation part of their documentation (because the BFO folks have a specific idea of how a definition should look like, they avoid the term "definition" for some of the high level classes). The elucidation for bfo:MaterialEntity reads: A material entity is an independent continuant that has some portion of matter as proper or improper continuant part. This makes reference to the even more general class of bfo:IndependentContinuant.

So, a thing is an instance of bfo:MaterialEntity if and only if it has some portion of matter as its part.

So an energy wave in my view most certainly (I am not a theoretical physicist) isn't a bfo:MaterialEntity. A tornado, in any practical application of BFO that I know of, would likely be described as a process (a bfo:Occurrent) in which numerous instances of bfo:MaterialEntity (grains of dust, droplets of water) participate. The terms "participate" and "being part" in this context (and in contrast to their colloquial use in everyday conversation) designate fundamentally different relations. In short, Material entities participate in a process (which in itself isn't a material thing) but may be part of a larger material entity.

For the proposed element as top level class for acommodating physical (material) entities, the important thing is that any item that ordinarily is dealt with in preparing, handling or using a collection object falls squarely into the scope of bfo:MaterialEntity, or, as it seems, dcterms:PhysicalResource.

Information artifacts are clearly separated from Material Entities in the BFO world as so called generically dependent continuants, which on a conceptual level makes a lot of sense to me.

[jbstatgen]

@cboelling Thanks for pointing further into the BFO. The sub-entries in the menu under "entity" are quite enlightening. Happily they seem to support some of our trains of thought so far. In addition, there is plenty more to think about.

Good to know that I'm not the only one who has been wondering about the examples for bfo:MaterialEntity.

While I might prefer "PhysicalResource" as term, I see the following:

• "Physical": a definition?
• "Resource": ethical concerns are arising with regard to 1) human remains and 2) objectification and "resourcifying" of nature

Thus, (a more narrow definition/use of) bfo:MaterialEntity might be a better choice.

[Jegelewicz]

What we are talking about in our context, I thought, is rather the "mass" than then "energy" part of "matter" (cp. the bfo:MaterialEntity editor note). dcterms:Physical Resource seems vague on the details - would that mean that it might be more fitting?

I am open to both PhysicalResource or MaterialEntity however, the MaterialEntity editor notes give me pause.

Also, what appropriate term will designate "not material" stuff? Can someone point to this in either DCMI or BFO? Although it isn't part of "MaterialSample" work, it will be important to know when one has a PhysicalResource or MaterialEntity and when one has whatever else we might be interested in.

I think the best definition I have heard for "material" is that it is something made of atoms. :-)

[tucotuco]

In BFO the independent continuant is divided into (and only into) material entity and immaterial entity. See https://ontobee.org/ontology/BFO?iri=http://purl.obolibrary.org/obo/BFO_0000004

Ignoring 20th century physics (sticking with atoms) may be fine for our use cases, but it grates on my inner physicist. ;-)

[Jegelewicz]

Ignoring 20th century physics (sticking with atoms) may be fine for our use cases, but it grates on my inner physicist. ;-)

Oh yeah! I feel that too - but it does seem appropriate for our use?

[cboelling]

Also, what appropriate term will designate "not material" stuff? Can someone point to this in either DCMI or BFO? Although it isn't part of "MaterialSample" work, it will be important to know when one has a PhysicalResource or MaterialEntity and when one has whatever else we might be interested in.

To answer this it would be helpful to have concrete examples of what you are thinking of with respect to not material stuff. For some entities BFO provides, in my opinion, an attractive framework to organize them and relate them to Material Entities. Note that BFO operates, as is my understanding, on the open world assumption. The classes in BFO are not meant to be exhaustive, it is valid to declare additional classes / subclasses in your own application.

[deepreef]

Chiming in to voice my general support on this! One word of caution, though:

The class dcmitype:PhysicalObject would clearly not work as a broader term (superclass) for dwc:Organism, as an Organism need not be inanimate.

I'm not sure if @tucotuco meant to suggest that dwc:Organism would be treated as a subclass of this new class (whatever the label ends up being), but I would strongly advise agaisnt representing it that way. It's really important from an informatics perspective to acknowledge that the "essence" of an instance of dwc:Organism transends its physical manifestation. An instance of dwc:Organism on the day of its birth shares very few atoms with that same dwc:Organism instance on the day of its death; yet informatically we want to treat them both as the same instance of dwc:Organism.

My inner physicist and inner biologist have discussed this with each other for many years.

[dr-shorthair]

Regarding the relationship between Organism and PhysicalObject or `PhysicalResource, I think the set-theoretic viewpoint is helpful here.

There is a class of Physical Objects.

There is a class of Organisms.

Some Things are both Physical Objects and Organisms - the classes intersect.

We do not have to assert that Organism is a sub-class of Physical Object to have both of these concepts involved.

[deepreef]

I definitely agree that Organisms are (mostly) physical stuff. But they're more at the "tornado" end of the spectrum (i.e., dynamic, with changing atoms over time, participate in actions in different locations at different times, etc.)

Conceptually, I can see an overlapping Venn diagram between dwc:Organism and dwc:PhysicalObject in the sense that some properties of an instance of dwc:Organism certainly involve physical matter.

But normally with set-theory diagrams like this (at least in our space), the diagram represents instances, as in some instances of dwc:Oragnism are also instances of dwc:PhysicalObject, but some instances of each are not also instances of the other. In this sense, I'm not sure a set-theory approach works (unless we're talking about sets of core properties, rather than sets of instances).

We do have to assert that Organism is a sub-class of Physical Object to have both of these concepts involved.

I'm not sure what you mean by "involved" here. Would you say the same thing about dwc:Location or dwc:Taxon? In my mind, the dwc:Organism class has informatic value that goes well beyond whatever physical manifestation a given instance of dwc:Organism happens to have at any given moment. In the same way that we represent relationships between dwc:Location-dwc:Event, or dwc:Taxon-dwc:Identification-dwc:Organism, we can also represent relationships between dwc:Organism-dwc:PhysicalObject. But I don't see why any of these relationships need to be represented as the superclass-subclass sort.

As something of a counter-point, one somewhat problematic aspect of treating something like a "specimen" as an instance of dwc:PhysicalObject is that, like dwc:Organism and tornadoes and such, the atomic composition of a preserved specimen also changes over time. It's just that these thre different things (specimens, organism, tornadoes) change their material composition at different rates.

That level of pedantry is probably unhelpful; but I remain uncomfortable regarding dwc:Organism as a subclass of dwc:PhysicalObject, unless it's constrained to an instance of an organism at a particular moment in time.

[dr-shorthair]

Whoops - a very important 'not' was missing - fixed now.

[jbstatgen]

@Jegelewicz Good question. I had agreed with @tucotuco about bfo:ImmaterialEntity, until @deepreef threw in dwc:Organism. That brought me back to a diagram that I had done early on in our work process (focus on overall structure)

Apparently the BFO deals only with bfo:Entities that are "tangible", ie. they are events (bfo:Occurrant) or tokens/evidence (bfo:Continuant). They belong to the row of subjective perceptions, even if they are bfo:ImmaterialEntities. BFO defines "immaterial entities" as boundaries or spaces, ie. the lumen of an intestine or nasal cavity. Thus, they are very much concrete.

Thus, the BFO doesn't seem to be developed for abstract concepts. In the diagram these include both the top row "Models" and the second row "Reality (abstract)". For me, occurrences, organisms and taxa are abstract concepts.

As part of the Material Sample group we are focusing on what we can actually perceive, grab onto of reality. We can catch the photons modified (? uuh, Physics 101) by an event (bfo:Occurrant) by a sensor in a digital camera, which points to an occurrence. We can cut wood and observe the lumen of its xylem vessels or dissect a moose and look at the size of the inside of its stomach. That is, the bfo:ImmaterialEntities are delimited/defined by concrete instances of bfo:MaterialEntities. Both are bfo:IndependentContinuants as subcategory of bfo:Continuant. All of these bfo:Occurrants and bfo:Continuants are subcategories of bfo:Entity, which seems to always refer to something concrete, tangible.

[deepreef]

I'm assuming your diagram was based on Darwin-SW, but if not, that means that three different groups independently arrived at a very similar modelling (the third group being Rob Whitton and I, who as part of the old NSF-BiSciCol project converged on exactly the same approach as Darwin-SW, except instead of "Token" we went with "Evidence".)

I agree that dwc:MaterialSample is a useful subclass of the proposed dwc:PhysicalResource (or whatever it ends up being called). My main point was to keep dwc:Organism as as separate thing (like dwc:Event, dwc:Location, dwc:Taxon, etc.)

[deepreef]

Whoops - a very important 'not' was missing - fixed now.

Ah! Makes much more sense! Thanks!

[jbstatgen]

@deepreef , yes the diagram is based on Darwin-SW, thanks a lot for pointing this out. For the full context and the many people who contributed see our discussion for issue #11 in the material-sample repository.

Your insertion of dwc:Organism I found very helpful, since it informed on @Jegelewicz 's question about "immaterial" entities. Your and @dr-shorthair 's comments provided, while having a different focus, to me the background for suggesting to differentiate bfo:ImmaterialEntity as part of concrete evidence from abstract concepts, something that hadn't been immediately obvious to me. I'm trying to catch up to what happened over night.

[jbstatgen]

One note about process: personally, given the work that has been done in the Task Group, and especially the outcomes of the recent working session on Nov 7 2022, I would have preferred if the motion to add this element would have been proposed in the Material Sample Task Group first to mint a joint proposal as a reflection of the contributions to the task group by a number of individuals.

@cboelling Until the working session after the conference, at least I had thought that the "materialSampleType" term had been sufficiently discussed, widely agreed on within the group and was unproblematic. The many comments and suggestions during the session showed that there were still open aspects. Personally, I am glad the discussion got reopened, because now the term that we will propose will have been set into a broader context and be mapped to and aligned with existing equivalent/similar terms. The proposal will be more solid for it.

Thanks a lot for reopening the discussion, so that @baskaufs proposed dcterms:PhysicalResource, and you pointed us to the BFO and its bfo:MaterialEntity.

[tucotuco]

Darwin SW is easily recognizable in the version of the GBIF Unified Model (see Appendix II and also https://github.com/gbif/model-material/blob/master/README.md) current as of the opening the the collections management systems mapping project, where Organism is a subtype of MaterialEntity, and MaterialEntity is congruent with bfo:material entity and dcterms:PhysicalResource.

[deepreef]

Organism is a subtype of MaterialEntity, and MaterialEntity is congruent with bfo:material entity and dcterms:PhysicalResource.

Yeah, I guess that's what I'm hoping to avoid. I can certainly imagine "BiologicalMaterial" or something like that as a subtype/subclass of MaterialEntity/PhysicalResource; but I see that as very different from dwc:Organism, which is as much (or more) an abstract entity as (than) it is a physical/material entity. This is/was the root of the fundamental issue about where an Organism ends, and a MaterialSample begins.

[jbstatgen]

@tucotuco Following your links and looking at your figure 2 (see above) of the README.md with fresh eyes and the discussion of the past days in the back of my mind, I have several questions.

The starting point for my inquiries is that I would like to understand what you need "Organism" for in the GBIF model to have it as subcategory of bfo:Entity? What is the role of the class in the GBIF model? What is it used for?

In your figure 2 you placed "Organism" in the same column as bfo:Entity and you also describe it as subcategory to bfo:Entity in your last post. However, the definition of dwc:Organism starts out with "Instances of the dwc:Organism class are intended to facilitate linking one or more dwc:Identification instances to one or more dwc:Occurrence instances. ..." This sounds more like the class being an abstract construct, maybe even "only" a tool and not something "real", tangible. It seems thus quite different from bfo:Entity

At the same time, bfo:Entity is the top category for bfo:Continuant and bfo:Occurent. Yet, you place "Occurence" to the side in a new column by itself, suggesting that it is something quite different.

Finally, I have become a fan of the PROV model, since I like to see the DES and the future of data modeling as fundamentally transactional with an event-based data model at their heart. The colored boxes denote the three foundational elements of the PROV standard: entities, agents and activities. In PROV they are all directly connected in a kind of triangle. In the GBIF model you are placing "Occurrences" inbetween the "Entities" and the "Activities". I don't understand why you need them there. I would appreciate it if you could explain and maybe provide an example.

For me, reality at some place and time results in an occurrence. In our perception we might focus on the rock facies component of reality (gneiss and basalt as igneous rocks, not sandstone) and not the organism(s) growing on its surface (eg. algae and lichens). The rocks and organisms can be classified according to some relationship/similarity/ancestry scheme. Up to now, the rock facies and organisms are abstract, general (universal? there is an expression for this) concepts. Once we move in an activity/event from the concepts to the specific instances, we have an empirical fact to collect, preserve and share, an entity.

Thus, I would at this point argue that dwc:Organisms are of a different "quality" than bfo:Entity, though will be happy to better understand your perspective on this.

[dr-shorthair]

Finally, I have become a fan of the PROV model

Me too. It also is fully consistent with BFO.

However, I have an issue with PROV subclassing prov:Agent to prov:Person and prov:Organization. I see persons and organizations as subclasses of prov:Entity (bfo:Continuant). Agent is a role that these entities can take in relation to a specific prov:Activity (bfo:Process which is a subclass of bfo:Occurrent) - i.e. prov:Entity and prov:Agent have an intersection, but this does not necessarily imply the sub-class relationship.

[baskaufs]

A few technical responses to comments made above.

1. A specific reason for suggesting that we import dcterms:PhysicalResource rather than some similar term from another vocabulary or ontology is that the DCMI terms are very stable and unlikely to change because they are strictly controlled by the DCMI Usage Board. It is also the case that thus far the only terms imported into the Darwin Core vocabulary have been from Dublin Core, and this proposal follows that pattern as well. In the past it has been suggested that terms from various OBO ontologies be used in Darwin Core, but we have thus far avoided importing them directly since they are not controlled by a standards organization and are subject to change without due process. I'm not up on how BFO is managed, but I don't think there is a standards organization behind it. This is not to say that external ontologies cannot be referenced in TDWG terms -- we've done that in both the ac:subtype controlled vocabulary (referring to the Getty Arts and Architecture Thesaurus) and the draft ac:subjectPart and ac:subjectOrientation controlled vocabularies (hopefully soon to be adopted; referring to various ontologies). So if we wanted to assert some machine-interpretable relationship without entailments to external ontologies as was done with the Audubon Core terms, we could do it. However, given the discussion above, it isn't clear to me that the meanings of dcterms:PhysicalResource and bfo:MaterialEntity are the same. So it might be a better idea to do the kind of soft mapping that we've done with DwC and MiXS terms, rather than asserting some kind of equivalence.
2. I would like to draw attention to current TDWG design patterns in labeling. In TDWG vocabularies, we distinguish between English human-readable labels and term local names (which are functionally the last part of the term IRIs). So for example, the term having the IRI http://rs.tdwg.org/dwc/terms/occurrenceAttributes has the local name occurrenceAttributes (as in dwc:occurrenceAttributes) but has the English label Occurrence Attributes. In DwC, we conflate labels and local names a bit because the Quick Reference Guide doesn't present the English labels (it just displays the local names). But the normative list of terms does and differentiates between the labels and the local names (as part of CURIEs). In Darwin Core, there is a pretty predictable pattern that links the human-readable labels and the local names: the labels are in human prose (words separated by spaces) and the local names are in lowerCamelCase for properties and UpperCamelCase for classes. If we import the term as proposed here, by default the label would be Physical Resource as that is what is given in the DCMI vocabulary. There is some precedent in Audubon Core for using labels that do not correspond to the term local names. For example, Audubon Core uses the label Copyright Statement for http://purl.org/dc/elements/1.1/rights (dc:rights), rather than the Dublin Core label Rights. I think this was to help clarify that a copyright statement was expected as a value. So we could potentially assert the human-readable label Material Entity for dcterms:PhysicalResource, but I don't see a benefit to this and if anything, it would add to the confusion we already have in Darwin Core between term local names and labels.
3. To follow up on @jbstatgen's comments about dwc:Organism:

In your figure 2 you placed "Organism" in the same column as bfo:Entity and you also describe it as subcategory to bfo:Entity in your last https://github.com/tdwg/dwc/issues/421#issuecomment-1330642945. However, the definition of dwc:Organism starts out with "Instances of the dwc:Organism class are intended to facilitate linking one or more dwc:Identification instances to one or more dwc:Occurrence instances. ..." This sounds more like the class being an abstract construct, maybe even "only" a tool and not something "real", tangible. It seems thus quite different from bfo:Entity

This is the reason why in my original proposal that I added that further discussion might be required to establish the relationship between the proposed new class and dwc:Organism. This issue has come up frequently before, but for those new to TDWG, dwc:Organism is not synonymous with a biological organism. As noted in the quote above, it was minted to serve as a node that would allow multiple occurrences to be linked to a particular individual, which could be a biological organism, but could also be a clone, wolf pack, colonial organism, etc. In fact, the name of the class was originally proposed to be called dwc:Individual, with a similar purpose (to be a linking node) but not actually including "organism" as part of its name. I have no doubt that as physical things organisms would be included in this new class, but I'm not sure about dwc:Organism. If occurrences go away, as they seem destined to do if the new GBIF model is widely implemented, then we may need to rethink the dwc:Organism class's definition.

I'll end with an apology if I gave the impression that I was trying to appropriate the work of the Material Sample task group (in which I participate). The idea that dcterms:PhysicalResource might be a suitable umbrella class for physical things came straight from the task group discussions. At the Material Sample working session earlier this month, some of the discussion seemed to be a repetition of what we'd discussed in the task group months earlier, with the flaws of the dwc:MaterialSample continuing to be a stumbling block. This proposal seemed to be a possible way to add clarity to the discussion so I went ahead and wrote it up. My apologies if that was out of line.

[deepreef]

I see persons and organizations as subclasses of prov:Entity (bfo:Continuant).

I imagine this is getting old, but I still think it's a fruitful approach, so I'll say it again that I see Agents as instances of organisms, which happen to have an Identification instance linking them to the Taxon, Homo sapiens. Organizations are, to me, effectively the same as wolf packs. I need to read up on prov:Entity, but if what you say above is true, then it's worthwhile thinking about it in the same way for dwc:Organism.

If occurrences go away, as they seem destined to do if the new GBIF model is widely implemented, then we may need to rethink the dwc:Organism class's definition.

I'm 99% sure that Occurrences are not going away, no matter what GBIF decides to do with its data model. Besides the obvious abundance of existing records, it serves a powerful informatic purpose for biological and non-biological sciences. Regardless of whether someone is interested in biological entities or non-biological entities, there is value in recording the presence of such entities at a particluar time and place. That value doesn't go away, even if the scope or term/label used to represent it (currently dwc:Occurrence) changes.

On a related point, as @baskaufs noted, when dwc:Organism was first proposed and debated, the term Individual was also considered. Neither term was perfect, because not all of the things we wanted to represent as instances of what is now dwc:Organism were individuals, nor were all of them organisms. But the term "Organism" ended up being adopted. In our active data model (alluded to earlier as converging with Darwin-SW), we called it "IndividualOrganism". We adopted that term because, like TDWG, we were biologically biased. In the next implementation of our model, I will likely go with "Individual" (with "Organism" as a subtype), because we use it to represent non-biological things (including non-physical things, like rainbows). But I digress...

The point I want to make is that, like dwc:Occurrence, the dwc:Organism class serves an important informatic function. While it may have begun its role in DwC as a node to allow multiple Occurrences to apply to the same individual (it was born of the deprecated dwc:individualID term, which had been organized in the Occurrence class), it's actual function in our domain (TDWG) is broader than this. The easiest way to get your head around what sorts of properties apply to an instance of dwc:Organism, is to think about what sorts of properties apply to you (see above). You are an instance of dwc:Organism, so whatever properties apply to you (taxonomic identity, occurrence across space and time, interactions and relationships with other organisms, etc., etc.), also apply to dwc:Organism.

[stanblum]

I have a few comments on the diagram @jbstatgen posted recently that was much like the DarwinSW model. Specifically I want to offer a simplified version that might help to show how subclassing and parsing concepts into multiple things can produce confusion in terminology. I've uploaded a simplified diagram to the MaterialSample repository, but also dropping it in here.

An Occurrence is the observation or sampling of an organism at place and time. I think it's also implied that an Occurrence comes into existence when a process occurs that produces a materialSample or an InformationArtifact (=token). It's also implied that the (collecting)Event is performed by an Agent (possibly a device), according to some method or protocol. So in this view, an Occurrence is the aggregate (relational joining) of all those data. Note that cardinalities among these entities in our models are such that if you know the MaterialSample, you also know the Event, Location, Agent, and Organism; because MaterialSample is in many-to-one relationships with all those entities. There is no need for an Occurrence entity separate from that join of data. Also, Token is a superclass (union) of MaterialSample and InformationArtifact. If the BFO demands that these are kept separate despite their similar relationships to the other entities in the model, then Token isn't necessary either. (But I'll continue using it here for convenience.)

The existence of a Token implies the existence of the Organism, but it has been argued that we don't need to create a separate record for the Organism unless there are multiple tokens, possibly from multiple Occurrences/Events. Manufacturing an OrganismID separate from MaterialSampleID might seem like an unnecessary burden for many situations -- creating what looks like a redundant entity/value -- but it might be the cleaner solution in the long run. Note that if we have both OrganismID and MaterialSampleID/InformationArtifactID, I don't think we need OccurrenceID. Occurrence was created only to serve as the Union class for specimen and observation, like Token was in DarwinSW.

Last, the necessity to explicitly create a record for an Organism, separate from MaterialSample, is not to link multiple Identifications (see the quote in Steve's prior post), but to link multiple MaterialSamples or InformationArtifacts. A single MaterialSample can have multiple Identifications; you don't need an Organism record until you have more than one MaterialSample from that Organism.

[jbstatgen]

I see persons and organizations as subclasses of prov:Entity (bfo:Continuant). Agent is a role that these entities can take in relation to a specific prov:Activity (bfo:Process which is a subclass of bfo:Occurrent) - i.e. prov:Entity and prov:Agent have an intersection, but this does not necessarily imply the sub-class relationship.

Food for thought, thanks @dr-shorthair ! This might contribute towards answering a gaggle questions that started to accumulate over the past few of months.

[jbstatgen]

@deepreef & @stanblum my impression is that we are going deeper into another topic and should separate it from the question of dcterms:PhysicalResource vs. bfo:MaterialEntity.

@deepreef I don't see that "Organism" or "Occurrence" will go away. They get more specific, maybe different, as well as importantly better defined functions and functionality. For example, I'm again wondering if "Organism" isn't already functioning as we expect a specific Digital Extended Specimen or a DiSSCo Digital Twin to operate.

@stanblum Your diagrams continue to be an inspiration, there is so much in them. With your diagram above, I only agree partly and we should at one point get together and talk our points of view through.

Right now, time constraints don't allow me to go further/deeper into this. Looking forward to do so at another time.

[jbstatgen]

Hi there!

Do we have all the topics and aspects on the table that we need to consider regarding dcterms:PhysicalResource and bfo:MaterialEntity?

If so, can we come to a decision which of the two terms to endorse for what had been called "Material Sample Type" and wrap this up?

Thanks a lot @baskaufs for moving us forward so productively!

[baskaufs]

@stanblum Thanks for the simplified diagram. The one think I would quibble about a little is that there really should be an arrow connecting the Identification and the Organism (i.e. taxonomically homogeneous thing). One uses the Token as evidence to make a determination, but the determination is "about" is the Organism, not the Token. If the Information Artifact is a photo and you make a determination of "Quercus alba", that's an assertion about the organism based on the photo as evidence, not an assertion about the photograph itself. This becomes important whenever collection of evidence is repeated (e.g. camera trapping) for the same Organism or when multiple forms of evidence are collected (photo, specimen, DNA sample) from the same Organism. If you make 3 independent determinations based on photo, specimen, and DNA from the same organism, you aren't assigning a Taxon to three different things. You are assigning it to one thing (the Organism) based on 3 different bits of evidence.

[Jegelewicz]

@baskaufs I don't think there is any need for an apology! If there is, then I should offer one as well since I was asked about this proposal before it was made and agreed it was a good idea.

[Jegelewicz]

Do we have all the topics and aspects on the table that we need to consider regarding dcterms:PhysicalResource and bfo:MaterialEntity?

The only thing that I see as an open issue here is this.

While I might prefer "PhysicalResource" as term, I see the following:

"Physical": a definition?
"Resource": ethical concerns are arising with regard to 1) human remains and 2) objectification and "resourcifying" of nature

@baskaufs noted

we could potentially assert the human-readable label Material Entity for dcterms:PhysicalResource, but I don't see a benefit to this and if anything, it would add to the confusion we already have in Darwin Core between term local names and labels.

So, can we go with MaterialEntity - which relieves us of the ethical concerns above, but make it equivalent with dcterms:PhysicalResource? Or does the definition - A material thing - offer the same problems (calling humans or parts of them "things") and also leave us wanting a definition of "material"?

We have been having this discussion for ages in Arctos - what is a "part"? At some level, I think we need to supply a line for when something is "material" and when it is not, but maybe we just let the user decide?

[albenson-usgs]

If so, can we come to a decision which of the two terms to endorse for what had been called "Material Sample Type" and wrap this up?

I may be misunderstanding but I don't think that's the intention here for PhysicalResource == materialSampleType. I think PhysicalResource is supposed to be a class like Occurrence, Event, Taxon, Location. The basisOfRecord terms (e.g. PhysicalSpecimen, FossilSpecimen, LivingSpecimen, MaterialSample) would fall under this class. Someone please correct me if I have this wrong.

[baskaufs]

@albenson-usgs I believe that you are correct in your interpretation

[baskaufs]

@Jegelewicz said:

While I might prefer "PhysicalResource" as term, I see the following: "Physical": a definition? "Resource": ethical concerns are arising with regard to 1) human remains and 2) objectification and "resourcifying" of nature

I do not think we should get too worked up about "resource". In the RDF world (which DCMI was trying to enter when it created the dcterms: terms), "resource" is just a term for "thing". See the definition of rdfs:Resource here. In fact, "resource" is the "R" in RDF (Resource Description Framework). If anyone has an issue with it, we ought to be able to just explain this to them. So literally PhysicalResource is a thing that is physical. There are many companies that have "HR" (human resources) departments and I find that WAY less objectionable than HCM (human capital management) as a departmental name.

As for fuzziness about "material" and "physical", I think there is a general understanding what they mean and definitions given in dictionaries seem to explain them clearly (for example "material"="denoting or consisting of physical objects rather than the mind or spirit.")

We have been getting really hung up on edge cases. If some of them are problematic, we can clarify in the term comments. The "made of atoms" general rule seems really sensible to me.

[baskaufs]

If we think that bfo:MaterialEntity is preferable to the proposed term, I think there are some policy questions that need to be addressed before going with it. As I said in my earlier comment, although there isn't any official TDWG policy recommendation on the subject, past precedent has been to avoid importing terms that aren't minted by some kind of standards organization. I would like to understand better the process by which BFO is managed and who exactly does the managing. If it's not by a standards organization, then I think we should run this by the Darwin Core Maintenance Group and possibly the TAG before going with it and setting a new precedent.

Based on the "bag of terms" philosophy, we have also been avoiding adopting terms that generate entailments from their defining metadata. dcterms:PhysicalResource has no entailments. I would want a clear understanding about what would be entailed by using bfo:MaterialEntity before we moved forward with adopting it.

[baskaufs]

I should add that my concerns about importing a term not issued by a standards organization is directly related to one of the three criteria that must be met by term changes (including additions): the stability requirement.

[stanblum]

@jbstatgen wrote:

@stanblum my impression is that we are going deeper into another topic and should separate it from the question of dcterms:PhysicalResource vs. bfo:MaterialEntity.

Yes, in retrospect I probably should have posted that in our MaterialSample discussion. My understanding is, like Abby's I think, is that dcterms:PhysicalResource is the class under which a MaterialSample <= (Preserved/Living/Fossil)Specimen, TissueSample fall under. So my comments didn't add anything to the topic issue here. Sorry! Happy to move those comments to the MS repo if that would help organization.

[cboelling]

tl;dr:

1. bfo:MaterialEntity is (like its immediate superclasses) designed to accommodate entities which persist through a (possibly brief) period of time, maintaining their identity while they undergo (possibly dramatic) changes in structure or composition. Instances of dwc:Organism fit right into this pattern. Asserting that dwc:Organism is a subclass of dcterms:PhysicalResource, of bfo:MaterialEntity, or a newly minted dwc:MaterialEntity inspired by the former, would be an entirely justified choice in this respect.
2. Likewise, based on their current definitions, dwc:MaterialSample, dwc:PreservedSpecimen, and dwc:FossilSpecimen, can be safely assumed to be subclasses of bfo:MaterialEntity.
3. The essential information to take this proposal, i.e introducing a top level class term for accommodating physical entities at a general level, is there, in my opinion. It will be more productive to separate concerns regarding the representation of evidence. I would expect numerous (and not necessarily disjunct) subtypes of dcterms:PhysicalResource in productive use to capture various aspects of the Material Entities that users are interested in (or whatever structure lends itself to provide them within DwC, e.g. as controlled vocabulary for a :MaterialSampleType element or classes proper. But this is a different discussion as well.
4. Having a dwc:MaterialEntity would help to highlight the conceptual equivalence to bfo:MaterialEntity even in the absence of a formal import of the latter into Darwin Core and connect DwC to an active, but matured field of research and development, capitalizing on the (in my view) more conceptually coherent and advanced scope of BFO.
5. If creating a top-level class in the dwc: namespace is admissible, I propose the following normative definition: A dwc:MaterialEntity is an entity that persists through some period of time, maintaining its identity, and has some portion of matter as a part at any given moment of its existence. This is basically a mashup of the definitions used in BFO, avoiding their technicalities.
6. I think that the next meeting of the Material Sample Task Group would be well suited to achieve consensus on these matters within the Task Group, and update / endorse the proposal accordingly.

To elaborate:

As @deepreef points out, organisms and preserved specimens change in their physical composition over time. Such changes, from the molecular level, to radical changes in structure or compositon during ontogeny (either genetically predetermined, like stages of metamorphosis or unexpected like losing a limb), to changes in aggregations of biological individuals (e.g., a flock of seagulls gaining or losing individual gulls) are entirely within scope of bfo:MaterialEntity. Instances of bfo:MaterialEntity can, without qualitative or quantitative limitations, gain or lose material parts, from atoms to arms, or undergo changes in their arrangement all the time. I believe that this does indeed cover all examples that have been given above. The essential thing is that a particular bfo:MaterialEntity despite changing in composition or structure maintains its identity. In some cases, there are clear-cut boundaries to this identity maintenance, but in others this may be thorny issue: How many individuals need to leave or come into a school of dolphin for the school to be the same school? How much must the process of decomposition after the death of a mouse advance so that the mouse ceases to exist? Whatever the answers to these and similar questions, from a conceptual viewpoint, at any stage these entities are instances of bfo:MaterialEntity, but not necessarily the same instance. Going from one stage to the next, generally requires some sort of process to kick in, with a Material Entity in an original stage entering the process and a Material Entity in a derived stage being the outcome of that process. Which stages and processes matter, should be identified, named and represented, and if a change of identity is involved is, I believe, very much up to our interests and subjects of inquiry.

In this light, I need to moderate what I said earlier about tornados. They, as a thing, do seem to maintain identity over time (meteorologists give them names, they persist for days) and they do have material parts (grains of dust, droplets of water). So they are bfo:MaterialEntities alright (sticking to the definition). What distinguishes a tornado from a wolf (it's late and I need to have some fun here too) is that the material parts of the former are in constant, turbulent motion and loosely tied to one another by an evolving system of atmospheric pressure while the material parts of the latter are in an infinitely more structurally conserved assembly, subject to change much more slowly and finely regulated through process like growth or metabolism. Given the incredibly general nature of bfo:MaterialEntity this is a distinction in degree, but not in principle. Adopting a process perspective instead (the "tornadoing" of the water droplets, or the "wolfing" of the molecules that happen to be part of a wolf body) would be possible in both cases but intuitively this makes no sense for wolves, but much more so for tornados.

BFO has been around for a number of years and has been adopted as upper-level structural scaffold by a large number of knowledge representation schemes. While this doesn't signal quality per se, it signals relevance. I don't think the upper-level classes, including bfo:MaterialEntity will undergo change anytime soon. Relating the new term to it, as proposed above, will be helpful to connect to other knowledge representation schemes.

[stanblum]

@baskaufs wrote:

The one think I would quibble about a little is that there really should be an arrow connecting the Identification and the Organism (i.e. taxonomically homogeneous thing).

My representation (Identification to Token) is:

1. from old training where the admonition is to minimize the number of relationships ("circles/loops among relationships indicate inconsistent business rules");
2. because a (properly scoped) Token has the same or narrower scope as Organism; if the wolf pack organism contains wolves and a husky/wolf hybrid, it needs to be broken into at least two organisms;
3. it's been argued by others that Identifications should be directed toward the stuff it's based on.

But I take your point that an identification that summarizes and represents a decision based on multiple Tokens would need to be attached to the Organism. But that kind of makes it different than the ID based on a narrower scope. So I guess an ideal Identification entity has the capacity to indicate specifically what it's based on.

[deepreef]

Wow... lots to read and catch up on. One quick reply to @stanblum:

So I guess an ideal Identification entity has the capacity to indicate specifically what it's based on.

So, in our approach, the Organism is an abstract thing, not a physical thing. It is the continuum of matter and energy (kinetic and potential) that begins at conception or mitosis or whatever (in the biological context) and ends at death or dissolution or whatever, but it is not limited to just the physical matter that might be observed by a human at a particular moment in time.

Thus, through this lense, the Identification is an assertion that one abstract entity (an Organism) is an exemplar of another abstract entity (a Taxon). What this assertion is "based on" is what we refer to as "Evidence" (=Token in Darwin-SW). The Scope of Evidence in our thinking includes things like MaterialSamples (the explicitly physical representation of Organisms), Images and other media, observations, documented information (e.g., publications). These are the tangible things that are not themselves the "Organism", but rather are physical and informatic derivatives of Organisms, upon which an taxonomic Idetnfication may be based.

So, yes, ideally we have the ability to link a single instance of Identification to multiple "Tokens" (evidence), that serve as the basis by which the assertion of a link between an Organism and a Taxon (i.e., the Identification instance) is made.

Incidentlly, the same kinds of Tokens can also serve as "evidence of Occurrence" as well as "evidence of Identification".

Not sure if that makes any sense...

[deepreef]

In response to @stanblum:

Note that cardinalities among these entities in our models are such that if you know the MaterialSample, you also know the Event, Location, Agent, and Organism; because MaterialSample is in many-to-one relationships with all those entities. There is no need for an Occurrence entity separate from that join of data.

I'll push back on this. I don't see an Occurrence as being the collective set of stuff cirumscribed by the Occurrence box in your diagram. If we consider an Event to be the intersection of a Location and Time (with various associated properties), then an Occurrence is an intersection of an Organism and an Event (with various associated properties). Similar to an Identification being an intersection of an Organism and a Taxon (with various associated properties).

As I noted in my previous post, I don't think it's correct to represent an Identification as being directly linked to the Token (MaterialSample/InformationArtifact), but rather directly to the Organism (this is implied within the definition of dwc:Organism). Instead, I see the Tokens (there may be many associated with a single Identification) as the "evidence" supporting that Identification.

I definitely agree that minting OrganismID values to generate an intersection node is "the cleaner solution in the long run". It's almost exactly the same situation as minting an IdentificationID value to apply a Taxon to an Organism (and, by derivitate extension, a MaterialSample or InformationArtifact).

Occurrence was created only to serve as the Union class for specimen and observation, like Token was in DarwinSW.

I agree that's why it was originally created, but I disagree that this represents its current value. The real value of an Occurrence is to represent the intersection of an Organism instance and an Event instance.

Last, the necessity to explicitly create a record for an Organism, separate from MaterialSample, is not to link multiple Identifications (see the quote in Steve's prior post), but to link multiple MaterialSamples or InformationArtifacts.

I think it's both. These aren't mutually exclusive informatic functions of Organism in the model. There may be multiple (competing/mutually exclusive) taxonomic identifications applied to a single Organism instance, and there may be multiple Tokens associated with an Organism (which can serve as evidence of identification, or evidence of occurrence, or both).

A single MaterialSample can have multiple Identifications; you don't need an Organism record until you have more than one MaterialSample from that Organism.

I disagree, for reasons already stated.

[stanblum]

@deepreef wrote:

If we consider an Event to be the intersection of a Location and Time (with various associated properties), [...]

This might highlight the difference(s) in our approaches to modeling. There are infinite locations on Earth; there are infinite points or intervals on the timeline. What makes some of them interesting to us is that a collecting/observing process took place where and when. So even if the result was zero (no specimens or observations), our interest and reason for recording/communicating about the when-where was the what, who, how.

Perhaps more to the point about Occurrence: I still assert that if you have:

Organism, Specimen/Observation, Location, Timeline, Agent, Method

Why do you need Occurrence? What do you want to say about it? Obviously, I'm trying eliminate anything that isn't essential. The sampling or observation of an organism at a place and time (by agent and method) tells the complete story. The only thing I can see is the binding together of multiple samples/observations in the same occurrence, when there might also be subsequent occurrences of the same organism. But those are all "joined" by having the same Organism and Event data, no? I'm repeating myself, but feel redundancy in here; i.e., Organism + Event = Occurrence so why create Occurrence?

[Heading out. I'll have a few hours to think more about this.]

[deepreef]

There are infinite locations on Earth; there are infinite points or intervals on the timeline. What makes some of them interesting to us is that a collecting/observing process took place where and when. So even if the result was zero (no specimens or observations), our interest and reason for recording/communicating about the when-where was the what, who, how.

Agreed, but that's kind of true for all DwC classes (infinite locations, infinite possible identifications, infinite measurements/facts, etc.) We limit the scope of instances to those that matter to us. But I'm in the camp that we define our classes around fundamental concepts. And to me, an "Event" is uniquely represented by the intersection of a place and time. Now, perhaps there is a need to mint multiple Events that share precisely the same place and time but differ only in terms of other properties (e.g., human participants, specific activities, etc.). That boils down to which properties of each class are definitive, vs. supplementary information. Maybe that's the level of definition we need to help avoid having different notions of what instances of these different classes actually mean.

As to your point about the (lack of) need for Occurrence -- I guess I need to think more about that. I mean, I think I could make the same argument that if you have:

Location, Timeline, Agent, Spcimen/Observation

Then why do we need Event? What do you want to say about an event that you can't say say with an aggregate set of instances and their properties?

I think the node of an Occurrence, defined more narrowly as an intersection of an Organism and an Event (not encumbered by "tokens" such as specimens/observations), serves an important informatic purpose -- in much the same way that an Event does.

The only thing I can see is the binding together of multiple samples/observations in the same occurrence, when there might also be subsequent occurrences of the same organism.

I think this is the crux of our difference here. To me, samples/observations are Evidence of Occurrences; they're not fundamental to Occurrences themselves. I see the Occurrence as the abstract presence of an organism (or non-biological thing) at a place and time. There are infinite numbers of them, but we only care to populate our databases with the tiny subset for which we have evidence to support them.

Good conversation! It's forcing me to think about this stuff in new ways.

[deepreef]

Now that I've caught up on the discussion, I owe an apology for falling into my usual trap of conceptual/philosiphical pedantry of only moderate (at best) relevance to the topic at hand. So... putting aside the definition and scope of Occurrence and Organism (which, to be fair, have at least some relevance), my own thoughts are: 1) I don't fully understand the implications of adopting dc terms vs. bfo terms, so I'll defer to the experts on that. 2) A lot of what we're doing is putting things into boxes to facilitate consistency in information representation and exchange. There will ALWAYS be edge cases. As noted by @cboelling, tornadoes and wolf packs differ in degree, not in kind; but for pragmatic purposes, our interest in the former is clearly dominated by it's kinetic and potential energy properties (with some interest in physical properties, such as when large tree branches and houses and such are hurled about), and our interest in the latter is clearly dominated by its physical properties (with some interest in kinetic and potential energy properties, such as behaviors and metabolic physiology). I imagine for most folks, the edge cases will be exceedingly rare, and most folks will have no trouble thinking of this class in terms of matter, rather than energy. 3) I really, really, really hope we don't represent Organism as a subclass of dcterms:PhysicalResource/bfo:MaterialEntity! (not because the material composition changes over time, but because the informatic utility of an Organism is more about its conceptual existence, than its material existence).

[stanblum]

I have to apologize, too. I modified my previous diagram a bit to accommodate some of the comments, but I hesitate to post it here and continue this thread about Occurrence, Event, Token, etc., because it's essentially peripheral or even irrelevant to the primary issue here -- the proposal to import(?) dcterms:PhysicalResource. @tucotuco, should we move these comments Occurrence to a discussion in DwC (not an issue)?

[cboelling]

2. A lot of what we're doing is putting things into boxes to facilitate consistency in information representation and exchange. There will ALWAYS be edge cases.

While it sometimes may seem frivolous, edge cases are most helpful in challenging our means for information exchange and sharpening our thinking. It's a good thing to continue to bring them up.

As noted by @cboelling, tornadoes and wolf packs differ in degree, not in kind;

... with respect to both of them being classified as bfo:MaterialEntities. Of course, there are innumerable ways in which these are different in kind with respect to other, more confined categories.

3. I really, really, really hope we don't represent Organism as a subclass of dcterms:PhysicalResource/bfo:MaterialEntity!

While I think that doing so would be entirely justified, would simplify things and would opt for this, I understand that declaring dwc:Organism a subclass of the proposed element is currently not part of this proposal.