New Term - dcterms:PhysicalResource #421
Comments
|
I support this!
For some discussions already in place see 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. |
|
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
<tdwg/material-sample#22>
tdwg/material-sample#23
<tdwg/material-sample#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
<#421 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADQ727V4MXPZ6O4B53JVV3WJZMATANCNFSM6AAAAAASJEOK5M>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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 Another comment relevant to this is that we should consider whether it's actually more appropriate to be using |
It's here |
|
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
added
Class - new
Task Group - Material Sample
|
Nice summary, @cboelling. The MaterialEntity class in the Unified Model originated in BFO, so there is perfect compatibility there. |
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. |
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.
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. |
|
@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:
Thus, (a more narrow definition/use of) bfo:MaterialEntity might be a better choice. |
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. :-) |
|
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. ;-) |
Oh yeah! I feel that too - but it does seem appropriate for our use? |
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. |
|
Chiming in to voice my general support on this! One word of caution, though:
I'm not sure if @tucotuco meant to suggest that My inner physicist and inner biologist have discussed this with each other for many years. |
|
Regarding the relationship between 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. |
|
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 But normally with set-theory diagrams like this (at least in our space), the diagram represents instances, as in some instances of
I'm not sure what you mean by "involved" here. Would you say the same thing about As something of a counter-point, one somewhat problematic aspect of treating something like a "specimen" as an instance of That level of pedantry is probably unhelpful; but I remain uncomfortable regarding |
|
Whoops - a very important 'not' was missing - fixed now. |
|
@Jegelewicz Good question. I had agreed with @tucotuco about Apparently the BFO deals only with 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 ( |
|
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 |
Ah! Makes much more sense! Thanks! |
|
@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 |
@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 |
|
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. |
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 |
|
@baskaufs wrote:
My representation (Identification to Token) is:
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. |
|
Wow... lots to read and catch up on. One quick reply to @stanblum:
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... |
|
In response to @stanblum:
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 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).
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.
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).
I disagree, for reasons already stated. |
|
@deepreef wrote:
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:
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.] |
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:
Then why do we need I think the node of an
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. |
|
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:
|
|
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)? |
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.
... with respect to both of them being classified as
While I think that doing so would be entirely justified, would simplify things and would opt for this, I understand that declaring |
|
Post it here before moving to DwC discussion, please, @stanblum. I’d like to know if it comes closer to our existing model or drifts away. |
|
I am in favor of the term as given in the original proposal. For me it defines the box we need for "things". The "Human Resources" argument is the best I've heard if someone should oppose the term for the ethics of using "resources" in reference to humans. I can certainly bring this before @tdwg/material-sample but I also see no reason they couldn't just comment here. Participation in meetings has dropped off and I don't want to have this decision be made by three or five people. I will email the task group members. |
Agreed! Indeed, it's the edge cases I always go to first to finesse where the boundary is. But there is often a point of diminishing returns where further scrutiny of rare edge cases impedes progress more than it enhances clarity and precision. In the age-old battle between the "perfect" and the "good enough" (which are often mutual enemies), I am often rooting for the "perfect" more than most people. But I also understand that this can be counterproductive. |
|
From the two main points of feedback (I think):
Key feature (a reveal to me; duh!) is that an Occurrence is then the intersection (association entity; M:M) between Event and Organism. [Revised to correct foreign keys in Token subclasses to be OccurrenceID instead of OrgansimID.]
Which looks almost the same as @jbstatgen 's first diagram, except for the use of arrows, I think. |
|
Only modification I'd make is that the Token box should also have an arrow pointing to Identification. Also, I'm a little fuzzy in my own mind about the exact relationship between Organism and Token. E.g., must it always pass through (at least) one Occurrence? So far, that's how we do it, and haven't found a need to change it. But does require expanding the scope of "Occurrence" to things like subsampling in a lab, or photo sessions not related to the time and place of the organism in nature. Ok, and like @Jegelewicz, I am likewise in favor of the term as given in the original proposal (to stay on topic...) |
|
My preference would be to name the new class term simply And make a new property term for And move to a controlled Would we in such a case want to rename I do prefer an explicit strong link to I agree with @deepreef that the "essence" of |
|
(I also think we do need a new class |
|
I realized that I have misused the dcterms: namespace abbreviation when writing my earlier comments in this issue. I think this has unnecessarily complicated the discussion for which I'm sorry. I have amended my earlier posts accordingly, especially here. I think this now partly resolves the concerns mentioned by @baskaufs (Apologies for stealing your time). Nonetheless, I stand by my proposal to formally link to |
|
@cboelling Since you are essentially suggesting a counter-proposal, I think it would be helpful if you would create a new issue using the new term template and fill out exactly what you are suggesting as the term's metadata properties. In particular, how would you propose to make the link to the external terms? In the efficacy justifications you can reference this proposal and succinctly summarize your arguments as to why your proposal is an improvement over importing If you are able to do that, I would like to request the members of the TAG to discuss the two proposals. In the past, if there was a well-known external term that captured the essence of what we wanted, we have imported it in preference to creating our own. In cases where our suggested use of the imported term was different or more specific than the use described by the minting organization, we have used non-normative "Notes" ( @tucotuco Can we add a field in the new term form for English label? It's not there presently and probably should be. |
|
@baskaufs The two issue templates have been updated to include "* Term label (English, not normative): ". |
|
Thanks @tucotuco |
|
Sorry to be late in much of what will follow here - not enough time to keep up consistently. There has been a lot of good discussion. Though there is a lot I would say about lots of comments in this issue, I feel compelled to answer questions specifically addressed to me. @deepreef from #421 (comment)
I would not suggest any subclassing in Darwin Core itself. This is something we once had with the values of @jbstatgen from in #421 (comment):
First, a point of information.
In the diagram for version 4.5 of the Unified Model, there is no implied significance of the "columns" of tables. Their arrangement is primarily a practical one to minimize clutter. The meaning is instead captured in the cardinality indicators in the connections between tables. Reading that from the diagram says that That quote above about Just because an
Again, the arrangement in columns is not meant to have special significance and formal alignment with BFO is not established. The significance is in cardinality of the relationships provided. In the Unified Model, an
In the Unified Model, as a subtype of
I hope my responses help. Let me know if they leave any doubts. @stanblum from #421 (comment):
It might have been a great idea to start this conversation in a Github Discussion in this repository, but given that all of this commentary has been transmitted via email to anyone who is watching the Darwin Core issues (with links to specific comments and such), it would be problematic to move them. I think that if we can periodically provide a summary-so-far comment of the stuff directly relevant to the proposal we should be fine staying here in this issue with the diverse connected conversations. If we come to any concrete conclusions about how to save the (modeling) world on related topics, we should probably do our best to make that happen in other appropriate places as well. For the Unified Model stuff, that would be GBIF's Discourse forum. |
In short, I see 3 alternatives:
I can do as you suggest but I would like to run this by the Material Sample Task Group. In my opinion, incorporating a top level term for material entities with accompanying metadata and documentation is the key result of this chartered task group, whichever alternative the TG gets behind.
These don't seem to be part of the new term form or is there a mapping? |
|
@cboelling The new term template is a little unclear about this, sorry. These patterns are historical artifacts and we probably should get our act together to make the terminology more consistent across documents. Hope this helps clarify. |
|
This was discussed at length today in the @tdwg/material-sample meeting. At this time, we plan to review the very detailed proposal made by @cboelling and make a decision on which of the three choices he proposed we prefer as a committee. That meeting is scheduled for January 18. We request that this proposal be held until at least until then. For more information and to join the discussion see tdwg/material-sample#31 |
|
Following the discussion at the January 18 metting, I would like to request that this proposal be withdrawn (closed) in favor of the proposal for |
New term
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.Proposed attributes of the new term:
The text was updated successfully, but these errors were encountered: