TG2-AMENDMENT_DCTYPE_STANDARDIZED

[iDigBioBot]

TestField	Value
GUID	bd385eeb-44a2-464b-a503-7abe407ef904
Label	AMENDMENT_DCTYPE_STANDARDIZED
Description	Proposes an amendment to the value of dc:type using the DCMI type vocabulary.
TestType	Amendment
Darwin Core Class	Record-level
Information Elements ActedUpon	dc:type
Information Elements Consulted
Expected Response	EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available; INTERNAL_PREREQUISITES_NOT_MET if the value of dc:type is bdq:Empty; AMENDED the value of dc:type if it can be unambiguously interpreted as a term name in the bdq:sourceAuthority; otherwise NOT_AMENDED
Data Quality Dimension	Conformance
Term-Actions	DCTYPE_STANDARDIZED
Parameter(s)
Source Authority	bdq:sourceAuthority is "DCMI Type Vocabulary" {[http://purl.org/dc/terms/DCMIType]} {"DCMI Type Vocabulary List Of Terms" [https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/2010-10-11/]}
Specification Last Updated	2024-08-16
Examples	[dc:type="evnt": Response.status=AMENDED, Response.result=dc:type="Event", Response.comment="dc:type contains an interpretable value"]
	[dc:type="X": Response.status=NOT_AMENDED, Response.result="", Response.comment="dc:type contains an uninterpretable value"]
Source	VertNet
References	Dublin Core (2012) DCMI Type Vocabulary. https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/
Example Implementations (Mechanisms)
Link to Specification Source Code
Notes	dc:type holds literals (e.g. PhysicalObject), while dcterms:type holds an IRI for the resource (e.g. http://purl.org/dc/dcmitype/PhysicalObject), see the Darwin Core RDF guide https://dwc.tdwg.org/rdf/#32-imported-dublin-core-terms-for-which-only-literal-objects-are-appropriate-normative. Implementations of this Amendment are expected be able to amend IRI values to the literals, as well as removing leading/trailing whitespace and correcting case errors in the literal.

[iDigBioBot]

Comment by John Wieczorek (@tucotuco) migrated from spreadsheet:
I believe the name of this test should be changed to DCTERMS_TYPE_STANDARDIZED for consistency.

[ArthurChapman]

I notice that the DCMI Metadata Terms are going to be specified in ISO 15836-2 (see https://www.iso.org/obp/ui/#iso:std:iso:15836:-1:ed-1:v1:en). Without paying for it, I can't see what that ISO Standard includes (https://www.iso.org/standard/71341.html) @tucotuco does that change any of the wording we have here - perhaps in the Prerequisites - rather than "A specified target source authority for dc:type" we reference ISO 15836-2 as we have done elsewhere

[ArthurChapman]

No idea where that thumbs down thing has come from in that description - can't get rid of it - sorry!

[tucotuco]

I would not reference the ISO standard because it is an unnecessary burden for people. The values are all available from the source at http://dublincore.org/documents/2010/10/11/dcmi-type-vocabulary/, so I would reference that.

[Tasilee]

I agree with @tucotuco. How do we therefore handle refs to "ISO 8601:2004(E)" as in #26, #52, #61, #66, #69 and #76?

[ArthurChapman]

OK - thanks @tucotuco . @Tasilee I don't think it changes the ISO:8601 as this is a well known standard and referenced everywhere for dates.

[ArthurChapman]

I have fixed the Reference.

[tucotuco]

@Tasilee, I agree with @ArthurChapman. ISO 8601 is well enough described in freely available documentation (e.g., https://en.wikipedia.org/wiki/ISO_8601).

[tucotuco]

Based on the naming precedent used for LICENSE (Issue #38), should the three tests for DCTYPE (#41, #91, and #103) be renamed as well?

[ArthurChapman]

I think I would be happy with that. Only problem, in the Taxonomic World "Type" has special meaning and I wonder if it might cause confusion just calling the test TYPE.

[tucotuco]

It shouldn't if a) we follow conventions diligently, b) we use TYPESTATUS for a typeStatus test, and c) people see what the results are telling them. ;-)

[Tasilee]

Changed the Expected response from

EXTERNAL_PREREQUISITES_NOT_MET if the DCMI type vocabulary is not available; INTERNAL_PREREQUISITES_NOT_MET if the value of dc:type is EMPTY; AMENDED the value of dc:type if it can be unambiguously interpreted as a value in bdq:sourceAuthority; otherwise NOT_AMENDED

to

EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available; INTERNAL_PREREQUISITES_NOT_MET if the value of dc:type is EMPTY; AMENDED the value of dc:type if it can be unambiguously interpreted as a value in bdq:sourceAuthority; otherwise NOT_AMENDED

[Tasilee]

Post Zoom 11/7/2023, I have aligned the Source Authority with the suggested syntax:

bdq:sourceAuthority is "DCMI Type Vocabulary" [https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/]

to

bdq:sourceAuthority is "Dublin Core Metadata Initiative (DCMI)" {[https://www.dublincore.org/]} {DCMI Type Vocabulary" [https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/]}

[Tasilee]

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Fields" to "TestFields" and "Output Type" to "TestType".

[chicoreus]

Source authority in changed format is unclear and if specified as a sourceAuthority, document locations have changed:

bdq:sourceAuthority is "DCMI Type Vocabulary" {[http://purl.org/dc/terms/DCMIType]} {"DCMI Type Vocabulary List Of Terms" [https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#section-7]}

Since the test is very tightly tied to the vocabulary, the vocabulary is stable and doesn't need a lookup, and needs to specify the vocabulary in the literal form rather than the IRI form, suggest changing the specification to:

INTERNAL_PREREQUISITES_NOT_MET if the value of dc:type is EMPTY; AMENDED the value of dc:type if it can be unambiguously interpreted as a term name in the DCMI Type Vocabulary (see bdq:sourceAuthority); otherwise NOT_AMENDED

[chicoreus]

Updated note to reflect guidance in Darwin Core RDF guide.

[chicoreus]

Changed the example from "evnt" to "event", as that is something that it is plausible to implement an unambiguous interpretation for. Expanding to soundex or near by string matches might isn't clearly specified under unambiguous interpretation.

[chicoreus]

Also should have the same sourceAuthority in #91 It notes that the type vocabulary can be found at: https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/2010-10-11/ suggesting the sourceAuthority for both this test and #91 should be:

bdq:sourceAuthority is "DCMI Type Vocabulary" {[http://purl.org/dc/terms/DCMIType]} {"DCMI Type Vocabulary List Of Terms" [https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/2010-10-11/]}

With expected response:

INTERNAL_PREREQUISITES_NOT_MET if the value of dc:type is EMPTY; AMENDED the value of dc:type if it can be unambiguously interpreted as a term name in the DCMI Type Vocabulary (see bdq:sourceAuthority); otherwise NOT_AMENDED

[Tasilee]

Agree on Source Authority to "bdq:sourceAuthority is "DCMI Type Vocabulary" {[http://purl.org/dc/terms/DCMIType]} {"DCMI Type Vocabulary List Of Terms" [https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/2010-10-11/]}" (changed)

but Expected Response should still have an "EXTERNAL_PREREQUISITES....."?

[ArthurChapman]

I'd have thought yes! If the source authority can't be reached then EXTERNAL_PREREQUISITES... applies

[Tasilee]

Amended Expected Response to

EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority is not available; INTERNAL_PREREQUISITES_NOT_MET if the value of dc:type is EMPTY; AMENDED the value of dc:type if it can be unambiguously interpreted as a term name in the bdq:sourceAuthority; otherwise NOT_AMENDED