-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Best practices for borrowing terms from other vocabularies #39
Comments
The future will require standards to support reasoning and with that machine-actionability. Already now the question of hierarchies is acute, eg. in the Material Sample and LtC task groups. Thus, a best practice should pre-prepare DwC for structure and relationships based on meaning, logic and functions. |
Yes, I can confirm this, but the design was mostly to have a well-entrenched model to work from and extend, not from any particular commitment. |
I agree, but should this be done piecemeal starting now, or should it be done as a comprehensive task? |
|
That seems to be a good starting point for a dedicated TDWG strategy process and/or a task group. @baskaufs asked for succinct answers and to refrain from discussions, a focus that I support. I also don't have the resources to go into thematic work at this point. |
If there is specific input of the TAG beyond what is documented in the TAG meeting notes linked above, please let the Material Sample TG know. Regarding the technical questions above: Re1: Re2: Re3: |
@cboelling I requested discussion in the TAG slack, but thus far (morning before MS TG meeting) there has been little discussion other than some general discussion about using SKOS to do mappings. At the meeting, it was suggested that members with perspectives on past practices should attend the MS TG meeting where this will be discussed. I think that @tucotuco plans to attend. I can't make the first meeting due to a staff meeting, but I plan to attend the second one. With respect to your Re2: comment. I agree that if one imports a term with entailments, that we need to accept them because we don't know whether users may use that term in a situation where those entailments may be computed automatically. That's why the current TDWG standards governing term creation (SDS and VMS) specify that we should start with terms at the "bag of terms" level and add the semantics as layers on top of that. This approach didn't come out of a vacuum. There was a massive discussion involving the community broadly via the TDWG email list between 2009 and 2011 (summarized here) about RDF and Linked data and it's role in Darwin Core and in TDWG in general. The "bag of terms" + layers approach came out of that discussion and was incorporated as a consensus view into the SDS and the VMS when they were written. That consensus and TDWG adherence to that approach since then is the reason why we need to consider carefully whether we want to deviate from it in this proposal. With respect to the Re3: comment: Yes, it is permissible to have opaque local names. That has generally been the practice with controlled vocabularies (see for example this where there are term names like |
This was discussed at the 2023-09-11 TAG meeting and the TAG requested that this issue be taken up by the Mapping Task Group. @DavidFichtmueller indicated that it would be added to the tasks of the Mapping Task Group in its draft charter. |
@baskaufs : You mixed up the date from the last meeting there with the date from yesterday. I thought for a second, that I had missed the meeting yesterday and wondered why I had it in my calender for Monday. |
Thanks for catching that, David! I've fixed the error. |
The Material Sample Task Group was charged with cleaning up some of the confusion surrounding terms used to describe material objects in Darwin Core. To facilitate this, a proposal was made to borrow the term
dcterms:PhysicalRecource
from Dublin Core to use as a parent class for all kinds of material objects. During discussion of this proposal, several counter-proposals were summarized in the Material Sample issues tracker. At the 2023-01-18 Material Sample TG meeting, the group plans to recommend one of the alternatives as a consensus recommendation to be proposed for addition to Darwin Core.This issue raises several questions about best practices for borrowing non-TDWG terms to become an official part of a TDWG vocabulary. If the TAG has any thoughts about the technical merits of the different approaches, it would be timely to express them prior to January 18 to provide advice to aid the Material Sample TG in their decision-making.
Existing practice within TDWG
Darwin Core currently borrows one class term (
dcterms:Location
) and nine property terms from Dublin Core DCMI Metadata Vocabulary. I believe that Darwin Core was designed to be “Dublin Core-like” in its structure and operation. (@tucotuco can you confirm this?) Darwin Core does not officially import terms from any other non-TDWG vocabulary, although several are recommended for use when expressing Darwin Core as RDF. These Dublin Core terms are versioned and an attempt has been made to be explicit about the version that was incorporated into Darwin Core.There have been some proposals to import terms from other vocabularies (for example tdwg/dwc#40 and tdwg/dwc#38), however thus far none have been adopted.
Audubon Core borrows many terms from several other non-TDWG vocabularies. During the creation of Audubon Core, I believe that the task group operated under the principle that they should only mint new terms when there was not a well-known existing term that could be used. The issue arose about what should happen if the non-TDWG terms were updated to new versions and the Audubon Core Maintenance Group adopted a policy that non-TDWG terms should be frozen at the version originally adopted unless an explicit decision was made to update them.
The Vocabulary Maintenance Specification states in Section 1.4 that TDWG vocabularies include simply-defined terms without range and domain declarations or additional semantics. Those terms can be enhanced by adding additional feature layers that generate entailments.
Technical questions:
dcterms:PhysicalResource
) or to mint a more narrowly defined term (e.g. mintingdwc:MaterialEntity
) that has meaning that is more specific in its intended use?bfo:0000040
; material entity) or should TDWG mint its own term (e.g.dwc:MaterialEntity
) and link it formally or informally to the more well known term to keep the new term at the “bag of terms” level?bfo:0000040
would deviate from the current practice of limiting class local names to UpperCamelCase English phrases. (Controlled vocabulary concepts currently have opaque local names.) Is that a problem?Please note that this issue is primarily concerned with the general principles illustrated by these alternatives rather than the merits of the specific alternate proposals themselves (i.e. not concerned with details of the definitions, exact choice of labels, etc.).
Please express relatively succinct opinions as comments here. For complex or extended discussion, please use the TAG Slack channel. This topic will also be discussed at the 2023-01-09 TAG meeting.
The text was updated successfully, but these errors were encountered: