tdwg / abcd Goto Github PK

View Code? Open in Web Editor NEW

13.0 23.0 5.0 46.05 MB

Access to Biological Collection Data (ABCD)

Home Page: https://abcd.tdwg.org

tdwg standard biodiversity-standards

abcd's People

Contributors

Stargazers

Watchers

Forkers

mattblissett kijucook dennereed warreg samira-babalou

abcd's Issues

Add element for agent who issued an aquisition

In ABCD there is an element wasAcquiredFrom to document where an object has been acquired from. There are use cases in which historically relevant persons and/or organisations that issued the acquisition. Thus, it would be nice to have another element like wasAcquiredBy in order to document the respective information.

xml usage

Is there some documentation regarding the implementation of the standard from the .xsd schema into SQL?

next ABCD Interest Group Meeting on 2024-02-20 during the TDWG Workshop Week

The next meeting of the ABCD Interest Group will be held on 20. February 2024 at 15:00 UTC (16:00 CET, 10:00 EST) during the TDWG Workshop week.

The meeting will be hosted centrally by TDWG. Information on how to register or the link to the conference itself will be communicated here once the details are sorted out. This issue is primarily a safe-the-date notice for all who are subscribed here. If you plan to attend, feel free to leave a comment or a thumbs up emoji under this issue.

The agenda for the meeting will also be added here ahead of the meeting.

Record Basis enumeration does not match ABCDEFG implementation

While working on the ingestion of ABCDEFG data we has some issue ingesting data coming from several BioCase instances.
In the 2.06 which most instance use the RecordBasis is a controlled vocabulary consisting of these elements:
"PreservedSpecimen","LivingSpecimen","FossileSpecimen","FossilSpecimen","OtherSpecimen","HumanObservation","MachineObservation","DrawingOrPhotograph","MultimediaObject","AbsenceObservation"
However in the EFG XML other types of RecordBasis, resulting in XML which does not validate against the ABCD schema.
This gives validation errors such as:
cvc-enumeration-valid: Value 'MineralSpecimen' is not facet-valid with respect to enumeration '[PreservedSpecimen, LivingSpecimen, FossileSpecimen, OtherSpecimen, HumanObservation, MachineObservation, DrawingOrPhotograph, MultimediaObject]'. It must be a value from the enumeration.

BioCase instances produces invalid data should be something to be avoided. However, there are already applications dependent on these (invalid) types being in in the RecordBasis. For example GeoCase uses this to populate the Specimen Type.

If I look at the 3.0 version of ABCD there is now some space to include geological specimen in the ABCD standard with the new RecordBasis type MineralSpecimen. However, with the BioCase providing EFG data we already noticed a kind of standard for the types, which are also used in GeoCase. The following types we have seen used:
"Unspecified", "RockSpecimen", "MineralSpecimen", "MeteoriteSpecimen"

As these types are already semi standardized and actively used within both the BioCase EFG instances and the GeoCase portal I would propose to include also the other types into the ABCD standard.
Additionally I would like to propose that before data is exchanged the data is validated so we are sure that all ABCD(EFG) data communicated complies to the data standard.

Interested in what other think regarding this subject.

For an example of a ABCDEFG from TalTech which uses RockSpecimen see:
https://bc.geocollections.info/querytool/raw.cgi?dsa=sarv&filter=(inst=Department%20of%20Geology,%20TalTech)AND(col=GIT)AND(cat=374-5)&schema=http://www.tdwg.org/schemas/abcd/2.06&wrapper_url=https://bc.geocollections.info/pywrapper.cgi?dsa=sarv

Links to rs.tdwg.org/abcd return 404

On http://tdwg.github.io/abcd/ABCD_v206.html I clicked the first link (http://rs.tdwg.org/abcd/) and noticed it returns a 404. Does http//rs.tdwg.org/abcd still exist?

In the ontology, using SKOS matching properties for classes precludes OWL DL

In line 136 of the abcd_concepts.owl file, the following triples are asserted:

    <owl:Class rdf:about="Contact">
        <skos:exactMatch rdf:resource="http://xmlns.com/foaf/0.1/Agent"/>
    </owl:Class>

In Turtle serialization:

<http://rs.tdwg.org/abcd/terms/Contact> rdf:type owl:Class.
<http://rs.tdwg.org/abcd/terms/Contact> skos:exactMatch foaf:Agent.

In section 8.6.2 of the SKOS reference the domain and range of skos:semanticRelation are the class skos:Concept. In section 10.3, we see that skos:exactMatch is a sub-property of skos:closeMatch, skos:closeMatch is a sub-property of mappingRelation, and mappingRelation is a sub-property of skos:semanticRelation. Therefore, the domain and range of skos:exactMatch are also skos:Concept.

Using skos:exactMatch therefore entails that

<http://rs.tdwg.org/abcd/terms/Contact> rdf:type skos:Concept

(see Example 57 in section 10.6.1 for an illustration of this). Thus, <http://rs.tdwg.org/abcd/terms/Contact> is an instance of skos:Concept, or in OWL terminology, it's an "individual".

Section 5.2 of the SKOS Primer discusses the implications of modeling a resource as both an individual and an owl:Class. OWL Full does not require classes and individuals to be disjoint, but an OWL-DL ontology has a distjointness condition for classes and individuals. SKOS does not take a position on this issue, but making such a statement would preclude considering ABCD from being an OWL-DL ontology.

I don't think that TDWG currently has any kind of policy about how ontologies should be constructed, but past discussions on the tdwg-content email list seemed to indicate that it was desirable to take care about making statements that resulted in unanticipated entailments. That's one of the reasons that the Standards Documentation Specification recommends in section 4.5 that properties that extend the meaning of terms by introducing machine-computable entailments be included in a separate vocabulary extension list rather than including them directly with the basic properties.

Whether it is a good idea to use SKOS properties in ontologies or not is a topic for debate, but I think that the discussion in section 1.3 of the SKOS Reference is relevant. It discusses the philosophical differences in the outlook between constructing an ontology and constructing a thesaurus. In writing the Standards Documentation Specification, this kind of discussion is what informed the decision that controlled vocabulary terms should have the type skos:Concept and that they should be distinct from property and class terms (section 4.5). In defining classes and properties, we are describing the universe, but in defining controlled vocabulary terms we are trying to get people to correctly categorize values by presenting them with preferred labels for their choices.

So although using the SKOS semantic relation properties in definitions of datatype properties (e.g. line 1018 of the ontology) don't cause the same OWL-DL issue as using them in class definitions, it still is worth considering whether it makes sense to assert that http://rs.tdwg.org/abcd/terms/areaClass is both a property and a skos:Concept. Similarly, does it make more sense to assert that http://rs.tdwg.org/abcd/terms/Celsius is an instance of the class http://rs.tdwg.org/abcd/terms/temperatureScale (as is done in line 6407) than to say that http://rs.tdwg.org/abcd/terms/Celsius is a skos:Concept that is part of the skos:ConceptScheme http://rs.tdwg.org/abcd/terms/temperatureScale ? That's what is implied to me by the way it's described at http://wiki.bgbm.org/entity/Q805.

I hope I'm not sounding too critical about the work done on the ontology document so far. It's really awesome and a great step forward. I just wanted to bring up some modeling issues that should probably be considered as you work.

By the way, there are no entailments generated when using skos:definition or any of the SKOS label terms since they don't have domain declarations. So they can be used "safely" with any kind of resource.

use of spaces in local names results in invalid URIs

In the abcd_concepts.owl file, values for vann:termGroup have local names that contain spaces. For example, line 20 has:

<vann:termGroup rdf:resource="Specimen Unit"/>

When combined with the base namespace for the ontology (http://rs.tdwg.org/abcd/terms/), this forms a URI object for the triple with a space in it: http://rs.tdwg.org/abcd/terms/Specimen Unit. This can be seen when the OWL file is loaded into a triplestore and queried. Here's an example:

        <result>
            <binding name='term'>
                <uri>http://rs.tdwg.org/abcd/terms/Accession</uri>
            </binding>
            <binding name='group'>
                <uri>http://rs.tdwg.org/abcd/terms/Specimen Unit</uri>
            </binding>
        </result>

Since URIs with unescaped spaces are invalid, it would be safer to replace the local names having spaces with ones using CamelCase.

I didn't check for other places where this happens, so it might be in other places than the values of vann:termGroup. That's just where I noticed it.

What is the current position of ABCD with regard to person identifiers?

Can a person be uniquely identified with one of more identifiers in ABCD?
Is there any plan to include it in future versions?

add element degreeOfEstablishment and pathway (with their controlled vocabularies)

In order to flag cultivated/captivated specimens as such it is highly recommended to use the appropriate dwc fields in ABCD too instead of inventing new ones. It will enable the use of e.g. "PreservedSpecimen" and "MaterialSample" as recordBasis for preserved material collected in an ex situ environment, such as a Zoo or Botanic Garden.

https://dwc.tdwg.org/terms/#dwc:degreeOfEstablishment with controlled vocabulary: https://dwc.tdwg.org/doe/
examples: cultivated, captivated

https://dwc.tdwg.org/terms/#dwc:pathway with controlled vocabulary: https://dwc.tdwg.org/pw/
examples: "botanic garden/zoo/aquaria (excluding domestic aquaria)", "conservation or wildlife management"

Something like "application/abcda" ?

Would be great to have a way to describe the format similar to a https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types way.

Thanks!