[PROPOSAL] Reimagine SWEET as a compilation of textual definitions

[lewismc]

Summary

The SWEET ontology suite should fulfill the role of a junction for textual definitions. An example can be found below

###  http://sweetontology.net/matrSediment/Soil
:Soil rdf:type owl:Class ;
      rdfs:subClassOf :Sediment ;
      rdfs:label "soil"@en ;
      skos:definition [
           dcterms:source <http://www.wikidata.org/entity/Q36133> ;
           rdfs:comment "natural body consisting of layers that are primarily composed of minerals"@en ] ;
      skos:definition [
           dcterms:source <https://gcmd.earthdata.nasa.gov/kms/concept/3526afb8-0dc9-43c7-8ad4-f34f250a1e91> ;
           rdfs:comment "The range of dynamic natural bodies composed of mineral and organic materials and living forms in which plants grow."@en ] ;
      skos:definition [
           dcterms:source <http://id.agrisemantics.org/gacs/C113> ;
           rdfs:comment "Complex mixture of inorganic minerals (i.e., mostly clay, silt, and sand), decaying organic matter, water, air, and living organisms."@en ] ;
      skos:definition [
           dcterms:source <http://dbpedia.org/resource/Soil> ;
           rdfs:comment "Soil is a mixture of minerals, organic matter, gases, liquids, and countless organisms that together support life on Earth."@en ] ;
.

Context

During The ESIP Summer 2020 meeting, as part of the Plenary: Proliferation of Vocabularies in Solid Earth, Space and Environmental sciences: Which one should I use and which ones can I trust?, @dr-shorthair presentation titled Proliferation of vocabularies and services - feature or bug? asked the fundamental question of How to manage the diversity? (across vocabularies).

@dr-shorthair's narrative presented the following three scenarios.

1. Insert mappings from SWEET - in the original graph?

###  http://sweetontology.net/matrSediment/Soil
:Soil rdf:type owl:Class ;
      rdfs:subClassOf :Sediment ;
      rdfs:label "soil"@en ;
      skos:narrowMatch <http://www.wikidata.org/entity/Q36133> ;
      skos:closeMatch <https://gcmd.earthdata.nasa.gov/kms/concept/3526afb8-0dc9-43c7-8ad4-f34f250a1e91> ;
      skos:closeMatch <http://id.agrisemantics.org/gacs/C113> ;
      skos:exactMatch <http://dbpedia.org/resource/Soil> ;

2. Store mappings from SWEET - in a separate graph?

<http://sweetontology.net/matrSediment/Soil> skos:narrowMatch <http://www.wikidata.org/entity/Q36133> .
<http://sweetontology.net/matrSediment/Soil> skos:closeMatch 
            <https://gcmd.earthdata.nasa.gov/kms/concept/3526afb8-0dc9-43c7-8ad4-f34f250a1e91> .
<http://sweetontology.net/matrSediment/Soil> skos:closeMatch <http://id.agrisemantics.org/gacs/C113> .
<http://sweetontology.net/matrSediment/Soil> skos:exactMatch <http://dbpedia.org/resource/Soil> .

3. Role for SWEET as junction for textual definitions?

###  http://sweetontology.net/matrSediment/Soil
:Soil rdf:type owl:Class ;
      rdfs:subClassOf :Sediment ;
      rdfs:label "soil"@en ;
      skos:definition [
           dcterms:source <http://www.wikidata.org/entity/Q36133> ;
           rdfs:comment "natural body consisting of layers that are primarily composed of minerals"@en ] ;
      skos:definition [
           dcterms:source <https://gcmd.earthdata.nasa.gov/kms/concept/3526afb8-0dc9-43c7-8ad4-f34f250a1e91> ;
           rdfs:comment "The range of dynamic natural bodies composed of mineral and organic materials and living forms in which plants grow."@en ] ;
      skos:definition [
           dcterms:source <http://id.agrisemantics.org/gacs/C113> ;
           rdfs:comment "Complex mixture of inorganic minerals (i.e., mostly clay, silt, and sand), decaying organic matter, water, air, and living organisms."@en ] ;
      skos:definition [
           dcterms:source <http://dbpedia.org/resource/Soil> ;
           rdfs:comment "Soil is a mixture of minerals, organic matter, gases, liquids, and countless organisms that together support life on Earth."@en ] ;
.

Current semantics

skos:defintion's are currently stored in SWEET as follows

###  http://sweetontology.net/matrSediment/Soil
:Soil rdf:type owl:Class ;
      rdfs:subClassOf :Sediment ;
      rdfs:label "soil"@en ;
      skos:definition [
           dcterms:source <http://www.wikidata.org/entity/Q36133> ;
           rdfs:comment "natural body consisting of layers that are primarily composed of minerals"@en ;
          dcterms:created "2020-07-20T17:15:28.345"^^xsd:dateTime ;
           dcterms:creator <https://orcid.org/0000-0003-2185-928X> ] ;
.

At the Aug 11th, 2020 ESIP SemTech Committee meeting this topic was discussed with the driving commentary being that although SWEET is well known in the ESSI space, other resources present appealing alternatives due to SWEET's limited axiomatization. One such example is ENVO which clearly offers an improved option from a curation perspective.

At it's core, this proposal seeks to acknowledge the above situation by strategically re-positioning SWEET as a junction for textual definitions. Several attendees at the Aug 11th, 2020 ESIP SemTech Committee meeting stated explicit support for this motion.

Request for comment(s)

This thread will act as means for obtaining community desire. Please comment below.

[lewismc]

I am +1 for this proposal. #208 provides a semi-automated mechanism for achieving this.

[rrovetto]

I recommend further examination and discussion of the topic. This is an opportunity to determine what each direction would look like, and the potential downstream pros or harms for each. The question and brief discussion during the 11 Aug meeting wasn't quite clear.

For example, as a junction, there may be risk of SWEET becoming ineffectual, merely a listing of others' resources, or replaced by some other resource. That is a concern, so for that particular direction, care and steps should be take to prevent those situations.

For example, another direction is this as an opportunity to develop SWEET further. A team can be set up (if distinct from the current group) to have tasks such as creating SWEET-specific descriptions/definitions for its terms in neutral manner, and adding logical axiomatizations. It would need to be decided whether to have both.

For example, an interesting direction may be a hybrid of the two.

etc.

[wdduncan]

Starting out with a disjunction of definitions at least gives you a place to start, and provides SWEET users with some (albeit not perfect) guidance on the meaning of terms.
I would be good to set up a review process to adjudicate conflicting or incorrect definitions.

[dr-shorthair]

Please note that the proposals re SWEET were at the end of the talk, and were just some musings building on work earlier that week by @lewismc on adding textual defs into SWEET.

The background is that SWEET is an important community resource with a long-standing reputation, but its role going forward is a little unclear. It is a large ontology covering a large scope, but its axiomatization is limited and that aspect has been overtaken by more recent work elsewhere. This proposal provides an updated role for SWEET, reflecting its widespread adoption for tagging. The core requirement is that textual definitions are available locally to SWEET users, so while there are several options for the mechanics, the expectation is that textual definitions are cached with SWEET. It was recognised that it is necessary that the provenance of these textual definitions incorporated be made very explicit. And if you are doing that for one source then there is no reason not to add text from other sources alongside.

Wikidata provides something of an exemplar for merging content, with provenance. However, the scope of Wikidata is much broader, and its content is not curated by a community or discipline.

[smrgeoinfo]

The 'junction of textual definitions' is a direction SWEET could take and getting some clarity that that is what SWEET is would be progress. This would essentially establish SWEET as what I would call a dictionary. Use case is 'I see this term as a tag for some resource, what might it mean?' Matching the term with a SWEET label would yield one or more definitions that are in use. Assuming that SWEET provides the concept URI associated with each definition, this gives a user the potential to semantically enhance the tag by associating it with a URI that identifies a single, clearly defined concept.
SWEET URIs thus identify a label/text string/name, that might have a binding to one or more concepts in different contexts. The utility of SWEET would be realized by including URIs (when available) for the distinct concepts (represented by text definitions) .

[rduerr]

So what I am hearing from above (along with some thoughts of my own) is:

1. SWEET is widely used globally to tag datasets
2. SWEET has few axioms and historically no definitions
3. There is a lot of work elsewhere being done to create well-axiomatized semantic resources for terminology that is also in SWEET (at least the high level terms)

corollary - dramatically changing the structure of SWEET as would be necessary to create a logically coherent well-axiomized ontology would

• Be a lot of work
• Potentially require existing users to equivalently dramatically change their existing tags
• Duplicates work that has already been done by a variety of disciplinary communities (a waste of already scarce resources)
• Would require more work to harmonize SWEET with those existing resources,
  - especially if SWEET's new axiomization is different from that within those resources and
  - unless SWEET added potentially thousands of new terms already covered by these other resources.

corollary - picking a single definition for any term in SWEET would:

• Potentially invalidate many of the tags already applied to data in various repositories where a different definition had been assumed
• Potentially restricts SWEET and its users to whatever assumptions the semantic resource the definition came from had

corollary - allowing multiple definitions from other semantic resources to be used for a single term in SWEET would

• Not require existing users to change their existing tags, though they may have to add their definition for a term to SWEET if they considered that definition to be sufficiently different than the existing set.
• Allows new uses of SWEET as a hub for semantic definitions of terms in the Earth and space sciences
• Does not commit SWEET to any upper level ontology as likely definitions will come from a wide variety of resources which may or may not already be harmonized and which may assume a variety of upper level ontologies or for that matter none.

I am sure this rather hasty analysis is not complete or for that matter completely accurate (please point out flaws where you find them); but from the above I'd have to say that I like the "dictionary" version of SWEET as a path forward .

[rrovetto]

The 'junction of textual definitions' is a direction SWEET could take and getting some clarity that that is what SWEET is would be progress. This would essentially establish SWEET as what I would call a dictionary. Use case is 'I see this term as a tag for some resource, what might it mean?' Matching the term with a SWEET label would yield one or more definitions that are in use. Assuming that SWEET provides the concept URI associated with each definition, this gives a user the potential to semantically enhance the tag by associating it with a URI that identifies a single, clearly defined concept.
SWEET URIs thus identify a label/text string/name, that might have a binding to one or more concepts in different contexts. The utility of SWEET would be realized by including URIs (when available) for the distinct concepts (represented by text definitions) .

In this scenario, adding local SWEET definitions, or an approximate intended meaning, can be done as well.

[dr-shorthair]

Good analysis @rduerr

[rrovetto]

Nice overview. Some input below.

So what I am hearing from above (along with some thoughts of my own) is:

1. SWEET is widely used globally to tag datasets

2. SWEET has few axioms and historically no definitions

3. There is a lot of work elsewhere being done to create well-axiomatized semantic resources for terminology that is also in SWEET (at least the high level terms)

Good points. In any case, though, we have the capability and freedom to develop SWEET further in those aspects, which may or may not have been the original intent of SWEET, and it can also be progress.

corollary - dramatically changing the structure of SWEET as would be necessary to create a logically coherent well-axiomized ontology would

The structure of SWEET, e.g., at least the subsumption hierarchy, is there. A logical formalization may not be as dramatic as one may think.
But more broadly, SWEET shouldn't become a mere showcase for other resources, e.g., it should not send the message 'this or that other resource has additional content (e.g. logical axiomatization) so go to that instead of SWEET'. That seems like an exercise and road to it being deprecated or replaced, which would be harmful. Instead, if viewed as an opportunity to further develop in some aspects, it may yield some innovative ideas. I'm not necessarily arguing/advocating only for that, but expressing the possibility and reiterating the concern.

* Be a lot of work

It may be more work, but how much is TBD, and may not be as much as one may think. But even if it is, who said hard work was easy. :-)
We should take care not to use work load as a reason to act or do things quickly or for the sake of showing that something is done. And a premature decision can be harmful to SWEET.

In general, questions of SWEET development include:

• include natural language defs? (e.g. local def)
• include computable definitions? If so, include logical axiomatizations, or some other method (some resources do not employ logics, but do interesting things all the same)?
• ...?

* Potentially require existing users to equivalently dramatically change their existing tags

Well, there's a possibility for change on all sides whenever any semantic resource makes a change. It happens all the time.
So again, we may be premature is say it would be a dramatic change. The perception of workload shouldn't drive away or toward something.
And since Sweet definitions aren't currently present, such an impact may not be as much as one may think.
We can ask users what their assumed meaning of the SWEET term they use is, whether they wrote a definition in their local system, etc.

* Duplicates work that has already been done by a variety of disciplinary communities (a waste of already scarce resources)

We shouldn't use 'duplication' in a pejorative sense, or as a reason to either not create, or to point to a particular product.
Because (a) the perceived duplicates may actually not be, i.e., not mirror images. The semantic resources we're talking about may have assumptions or axiomatizations that others do not; some may these have at varying degrees of abstraction.
This would mean it's not duplication, because the semantics/intended-meaning and assumptions are not equal.
(b) By not allowing the opportunity to create because of perceived duplication, innovation is hindered. We or anyone may have unique ideas or ways of conceptualizations or defining that can introduce insights not gleaned from other resources. And wrt natural language, we see that all the time in the use of language in various forms.

* Would require more work to harmonize SWEET with those existing resources,
  -   especially if SWEET's new axiomization is different from that within those resources and
  -   unless SWEET added potentially thousands of new terms already covered by these other resources.

Any resources with their own axiomatizations will already be work to harmonize or map with one another. I think we agree that a resource, including SWEET, shouldn't be forced to have the same axiomatization of some other resource. In general, each resources with axiomatizations can be different in the subtleties within that formalization, just as within a natural language definition. It need to be a full harmonization (whatever that would look like), but it could be specified to approximate harmonization: one resource with a natural language defintion of a term may be said to be approximately similar at the most immediate sense with that of another resource which has additional semantic baggage. But the the two may be determined and asserted as different at, say, at a abstract level which the latter may have in its additional semantic baggage. So it is always a good amount of work. The perceived workload should not deter.

corollary - picking a single definition for any term in SWEET would:

* Potentially invalidate many of the tags already applied to data in various repositories where a different definition had been assumed

Possibly but not necessarily.
First, we need to know what, if any, the assumed definition is. If none, then it should not be so problematic, but we can ask if they agree with the definition and go from there. In general, with input (presumably from users) on defining a SWEET term, it may not be as daunting. Just as with trying to make a definition that a group can agree on, so I assume it would be similar in this case. An interesting prospect is the potential opportunity to form definitions that may be applicable to, as you mentioned in #1, the various data and users using SWEET terms.

* Potentially restricts SWEET and its users to whatever assumptions the semantic resource the definition came from had

This applies to all semantic resources. Any semantic resource that has one definition is a restriction or constraint. It may make assumptions on semantic and other dimensions, that may or may not be seen in the definition itself. This is especially true for semantic resources that use other more abstract resources (e.g. upper ontologies) which actually restricts and imposes more on the user that the user may want.

corollary - allowing multiple definitions from other semantic resources to be used for a single term in SWEET would

* Not require existing users to change their existing tags, though they may have to add their definition for a term to SWEET if they considered that definition to be sufficiently different than the existing set.

The idea of users being able to add their own definition is interesting, definitions they may or may not have explicitly stated in their work.
But besides that, the user may need to change something regardless of the definition they may use (their own or from external resource), if any. They may especially need to change something if the definition has a logical axiomatization, one-to-varying degrees/levels of abstraction.
In general, the more complex, and the greater degrees of abstract that an external resource or definition provides, the more the user should understand, in part because they may not agree with the definition (or its axiomatiaztion) at however many layers of generality.
If developing SWEET, I presume we can do so in a way with minimal complexity but consistent with the current sweet structure.

* Allows new uses of SWEET as a hub for semantic definitions of terms in the Earth and space sciences

* Does not commit SWEET to any upper level ontology as likely definitions will come from a wide variety of resources which may or may not already be harmonized and which may assume a variety of upper level ontologies or for that matter none.

I am sure this rather hasty analysis is not complete or for that matter completely accurate (please point out flaws where you find them); but from the above I'd have to say that I like the "dictionary" version of SWEET as a path forward .

[rduerr]

This might all be an issue of use cases... my immediate use case is to enable a large number of existing repositories to federate their discovery mechanisms without having to jump over lots of semantic and other technical hoops to just get their results to be comparable and useful to users which is, by the way, not the case today. In other words to be Findable!

Beyond that the semantic harmonization work should allow those datasets found to also actually be Accessed, Interoperable, and Reusable.

In other words, entirely utilitarian use cases. No semantic resources of academic quality or academic interest is of interest to me! I want stuff that works in the real world, with real data and real repositories. That's actually what the polar repositories community that I am working with have wanted for decades now!

So, having said that. I vote that we

1. do not axiomatize SWEET;
2. we merely add potentially multiple definitions to its terms as communities have time and energy to do so,
3. do minor cleanup of the hierarchical structures where they are clearly wrong or need clarification as defined by the communities when doing their work in 2
4. we do as much harmonization of SWEET to prominent vocabularies such as the GCMD keywords, USGS and NOAA thesauri, etc. as we can find parties to work on each of these
5. We encourage repositories to continue using SWEET to tag their datasets, noting that SWEET will be endeavouring to be GCMD, etc. compatible going forward (and asking for their help to make that so)
6. We advertise this expanded role for SWEET among repositories and agencies, etc.

Hopefully this will encourage repositories to contribute to this work, build community and start thinking outside of the box of their data when building systems, capabilities and tools.

Does this make sense?

[brandonnodnarb]

Whew. Can open. Worms everywhere. :)

I have a few follow up questions.

• Duplicates work that has already been done by a variety of disciplinary communities (a waste of already scarce resources)

Yes, a waste, especially when not uploaded to COR (or similar) either. :) In the past there were domain ontologies developed for, or subsequently added to, SWEET; Hydrogeology and Volcanology (IIRC) come to mind (i.e. not mapped to). I understand ownership, credit and the like can be a tricky thing, but is this sort of approach worth re-visiting?

1. SWEET is widely used globally to tag datasets

Is it? I've heard this ...more than thrice. Is this information gathered mostly from personal interaction or is there evidence somewhere one could point toward? Has there been any recent investigation? Are there any web/link analytics available from current (or any) SWEET URIs? (And the knock-on questions around how that might be leveraged alongside or within COR...)

Without allowing anyone time to answer :), would it be worth sending out a survey to ask questions in this regard? We did something similar for the Agrisemantics WG and the results were actually pretty interesting (output 2 is most relevant here). I'm wondering if a survey, obviously with a focus on geoscience semantic resources, make sense? Questions around what is used, why is it used, etc. Perhaps even loaded/leading questions around why SWEET is or isn't used, and so on.

At minimum it would provide some much needed insight to the overall "what is SWEET and where is it going" lingering question(s).

• Potentially require existing users to equivalently dramatically change their existing tags

Sure. I agree with @rrovetto. It's the way of things. ;)

To me, it does signal the governance of SWEET needs to be clear both in natural language terms and how PROV (I assume) is used.

4. we do as much harmonization of SWEET to prominent vocabularies such as the GCMD keywords, USGS and NOAA thesauri, etc. as we can find parties to work on each of these

5. We encourage repositories to continue using SWEET to tag their datasets, noting that SWEET will be endeavouring to be GCMD, etc. compatible going forward (and asking for their help to make that so)

Yes, and ideally the effort would be both ways. I don't think it an unreasonable ask for a thesaurus editor at NASA, NOAA, or the USGS to perform a quick search of SWEET when making edits or additions. If the links already exist it's a quick verification step.

What's really interesting in this proposal is the analog between SWEET, for Earth Sciences, and GACS, for Ag and Food --- or similar lines at least (paper has explanation and links). One of the reasons GACS has stalled is due to politics (to be polite) --- they have no ESIP equivalent (well, nothing that would garner any type of agreement). As ESIP is already in place, SWEET as a "semantic hub" could be quite powerful.

It's personally disappointing, but if that's what makes SWEET useful then so be it.

In reference to the actual issue, I think 2 and 3 seem quite usable. I would advocate for keeping them in separate graphs, at least for the time being. Modularity is an undervalued design technique and it would be nice to only import what is needed --- even if it turns out to be in theory only. :)

[lewismc]

Is this information gathered mostly from personal interaction or is there evidence somewhere one could point toward?

SWEET is accessed loads through COR. We can easily generate some numbers fro say a months worth of HTTPD server logs.

would it be worth sending out a survey to ask questions in this regard?

I would say yes. I think this is a good idea. It may go a long ways to cleaning up a lot of the hypothesizing above.

[pbuttigieg]

Discussed in our Semantic Tech call today:

• Agreement on SWEET as a junction: it's ambiguous as to who agreed to this and how. We need a more clear decision making process (xref the operations committee discussion in our Visioning session)
  • This is seen as a prerequisite for passing proposals like this - the issue tracker is better suited for narrow issues, rather than policy changes. However, if it is to be used this way (arguments for this are also present, esp. provenance tracking by linking to the issues), a clear SOP is needed.
  • Governance flows and decision making processes need to be defined - added as an agenda item for next SemTech call.

This will have significant consequences on what SWEET looks like and how technology interacts with it. This should be considered - those who have technology interacting with SWEET should be asked to comment.

Also, which definition will be used to build the hierarchy? Some will identify different super classes. Previous discussions have suggested not having the structure driven by definitions, but this has consequences for the semantic model. The Semantic Harmonisation definitions do, however, consider the hierarchy and suggested changes to it.

[graybeal]

Re the last point in the preceding comment ("Which definition will be used to build the hierarchy?"), I had a direct reaction in the meeting, which led to interesting questions about governance.

As noted, my reaction was that no one in the discussion about definitions (either this one or issue #125) had any thought that the definitions had any implication for the structure. I think we were assuming that a definition that did not fit the current structure (e.g., the realm) would obviously not fit, and so would not be included. I know my expectation was that since SWEET is not a seriously structured semantic resource, and opinions about structure can vary (especially as expressed in the definitions), I would not expect us to take on additional structuring just because a definition said it was so.

And so, there is no need to answer the question at the top of this comment, because we are not using definitions to build a hierarchy. All definitions are equally (un)important.

That does not mean the SWEET semantic model/structure can not be changed, just that the process of changing the structure should not be driven by the definitions. If independently everyone decides on a structural change, that should change what definitions are considered appropriate from then on.

But these are all my opinions. The other question this led to was "Who decided that we would start collecting definitions for SWEET? How are decisions for SWEET made?"

I guess this is progress, because until that moment I'd say SWEET decisions were made by Lewis based on agreement from the "interested community"—that is, people who responded to the tickets where the tasks were proposed. The advantage of that approach is that it is responsive to people who are most willing to invest the time to propose and implement a change. I'm not yet 100% convinced that the interest level will stay high enough to adopt a "strategic governance" model as opposed to a "task-driven governance" model (strategic is much more expensive!), but it's great if the interest and value is strong enough to support more strategic discussion. (We'd likely want a SWEET-specific call each month so it doesn't dominate SemTech calls.)

[lewismc]

Note, I've changed this proposal title to accommodate growing consensus from the attendees at the 2020-10-13 meeting.

Also, I'm going to cross-post all of the commentary from that meeting here

SWEET as a junction for “textual definitions”

* JG summarises his Sep [response](https://github.com/ESIPFed/sweet/issues/211#issuecomment-689894954) to our Committee post 
  - Key concept change - the multiple definitions are not there to build the hierarchy, but to record definitional range. The textual definitions are not necessarily there to drive the semantics.
  - The backbone semantics can be changed separately (may need some clarity on which defs drive that)
  - SWEET Decision making processes: until now, consensus from active community coordinated by Lewis. Interesting that more formal governance model is being suggested - are we ready for this?
  - The junction role is a compilation - that can feed forward to Semantic Harmonisation group to refine, that can feed forward to more semantically coherent resources in the Semantic Resources federations
* Notion of “textual definition” is to clarify that this refers to use of Annotation Properties in an RDF/OWL vocab (e.g. rdfs:comment or skos:definition), and not some axiomatized “definition” (e.g. logically defined necessary and sufficient conditions)
* Concern that “textual definitions” will contain terms that will not have clear semantics supporting them.  However, this is moderated by the fact that the original definitions, and their inclusion as annotations in SWEET, are both human-focused processes, not semantically rigorous content. (Issue deferred for further discussion on Semantic Harmonization cluster)

[wdduncan]

For those interested in doing more high-powered semantics, it might worthwhile to form groups to work on specific versions of SWEET. E.g., if we want a version of SWEET that makes heavy use of the OBO Foundry, we can create an OBO-SWEET ontology. I say this with caution b/c it might entail a lot of work that is difficult to get down without funding.

[lewismc]

This topic was discussed/debated at todays ESIP Winter working session.
Meeting notes
Breakout session notes
The 15 attendees participated in a VOTE (Yes or No) to support option # 3 from the proposals above. That is included below for convenience.

3. Role for SWEET as junction for textual definitions?

###  http://sweetontology.net/matrSediment/Soil
:Soil rdf:type owl:Class ;
      rdfs:subClassOf :Sediment ;
      rdfs:label "soil"@en ;
      skos:definition [
           dcterms:source <http://www.wikidata.org/entity/Q36133> ;
           rdfs:comment "natural body consisting of layers that are primarily composed of minerals"@en ] ;
      skos:definition [
           dcterms:source <https://gcmd.earthdata.nasa.gov/kms/concept/3526afb8-0dc9-43c7-8ad4-f34f250a1e91> ;
           rdfs:comment "The range of dynamic natural bodies composed of mineral and organic materials and living forms in which plants grow."@en ] ;
      skos:definition [
           dcterms:source <http://id.agrisemantics.org/gacs/C113> ;
           rdfs:comment "Complex mixture of inorganic minerals (i.e., mostly clay, silt, and sand), decaying organic matter, water, air, and living organisms."@en ] ;
      skos:definition [
           dcterms:source <http://dbpedia.org/resource/Soil> ;
           rdfs:comment "Soil is a mixture of minerals, organic matter, gases, liquids, and countless organisms that together support life on Earth."@en ] ;
.

The RESULTS were 92% Yes and 8% No meaning that the VOTE passes and that we resolve this issue and move forward.
Thank you to everyone that took part in the long thread.

Update (9 Feb): A few things should be noted for fairness and clarity. (1) The vote was abrupt and ad hoc, introduced after some members mentioned alternatives (not necessarily mutually exclusive) and expressing potential negative consequences of the junction approach. (2) Conducting a vote was not agreed to ahead of time. (3) Alternatives (including this proposal) were previously described in a document provided by a member, but were never discussed prior to the session. (4) Newcomers to the Winter meeting session were thereby not sufficiently informed (they were not in a position to make an informed decision). In all, this makes the vote questionable and should not have occurred (certainly not in that manner). In any case, a critically important point is having a shared desire to develop SWEET itself, not to spotlight or bias other resources.

[smrgeoinfo]

If SWEET classes represent a collection of definitions that might each have a different lexical representation (label, title, as suggested in #125), there should be some way to identify a specific definition if someone wants to reference one of the specific concepts (represented by a definition string). This is not possible if blank nodes are used for the definitions.