Use of controlled values for dc:type not in the DCMI type vocabulary

[baskaufs]

The 3D Imaging Task Group chartered by the Audubon Core Maintenance Group is considering proposing that "3D resource" (or some variation on that string) be used as a controlled value for dc:type (an existing term borrowed by Audubon Core). The rationale is that 3D images are at least as different from 2D images as videos, and there are existing values for "still image" and "moving image" in the DCMI type vocabulary.

The problem is that these are borrowed terms and TDWG does not control the recommended use of DCIM terms. The dc:type definition says “Recommended practice is to use a controlled vocabulary such as the DCMI Type Vocabulary”. Since there is no value for "3D resource" in the DCMI Type Vocabulary, how bad would it be for Audubon Core to recommend that people use "3D resource" as a value? Of course, we could probably request that DCMI add "3D resource" to the type vocabulary, but changes to Dublin Core are so infrequent that it's unlikely that the change would happen at any time in the foreseeable future.

For historical context, an early Executive Committee decision http://rs.tdwg.org/decisions/decision-2009-12-07_1 (see http://rs.tdwg.org/decisions for the full list) concluded that Darwin Core classes should not be used as values for dcterms:type in order to be consistent with the recommendations for the term. However, in this case, the Darwin Core term dwc:basisOfRecord was available to be used with Darwin Core class terms as values.

Audubon Core does not have any term that is an analog of dwc:basisOfRecord, so that solution is not available to us and in any case that was a somewhat idiosyncratic, jury-rigged solution anyway. One possible option would be to come up with some solution involving rdf:type, which does not have any particular recommended value, but which has the issue of expecting an IRI value (as opposed to dc:type for which literal values are acceptable).

We would really appreciate some guidance from the TAG on this issue.

[tucotuco]

In my view, a pragmatic way forward is to make a best guess at what the term would look like in Dublin Core (both the dc and dcterms versions), propose those to DCMI to ge tthat ball rolling, and start using them as a functional case study to back up the proposal. The worst case scenario is that Audubon Core users will have better capacity to express their media and Dublin Core users will find a violation of the controlled vocabulary that is human understandable. I speak from my own perspective, not as a definitive answer from the TAG.

…

On Fri, May 8, 2020 at 10:37 AM Steve Baskauf ***@***.***> wrote: The 3D Imaging Task Group chartered by the Audubon Core Maintenance Group is considering proposing that "3D resource" (or some variation on that string) be used as a controlled value for dc:type (an existing term borrowed by Audubon Core). The rationale is that 3D images are at least as different from 2D images as videos, and there are existing values for "still image" and "moving image" in the DCMI type vocabulary. The problem is that these are borrowed terms and TDWG does not control the recommended use of DCIM terms. The dc:type definition says “Recommended practice is to use a controlled vocabulary such as the DCMI Type Vocabulary”. Since there is no value for "3D resource" in the DCMI Type Vocabulary, how bad would it be for Audubon Core to recommend that people use "3D resource" as a value? Of course, we could probably request that DCMI add "3D resource" to the type vocabulary, but changes to Dublin Core are so infrequent that it's unlikely that the change would happen at any time in the foreseeable future. For historical context, an early Executive Committee decision http://rs.tdwg.org/decisions/decision-2009-12-07_1 (see http://rs.tdwg.org/decisions for the full list) concluded that Darwin Core classes should not be used as values for dcterms:type in order to be consistent with the recommendations for the term. However, in this case, the Darwin Core term dwc:basisOfRecord was available to be used with Darwin Core class terms as values. Audubon Core does not have any term that is an analog of dwc:basisOfRecord, so that solution is not available to us and in any case that was a somewhat idiosyncratic, jury-rigged solution anyway. One possible option would be to come up with some solution involving rdf:type, which does not have any particular recommended value, but which has the issue of expecting an IRI value (as opposed to dc:type for which literal values are acceptable). We would really appreciate some guidance from the TAG on this issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#27>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADQ723S2AIGW7XQE6MVHFTRQQDLHANCNFSM4M4FVPTA> .

[baskaufs]

A thought that I had after writing this is that perhaps it would be better to just abandon dc:type altogether and mint our own term that would be expected to have a SKOS concept as a controlled vocabulary. We could then construct the controlled vocabulary exactly as we want and express the hierarchical broader and narrower relationships clearly and exactly as we wish. That would get us out of the business of managing two separate terms (dc:type and ac:subtype). See the SKOS primer for an example involving "cats", "mammals", and "animals". One could express the type of media in the most specific way possible and the broader categories would be implied.

[tucotuco]

That also seems viable and with its advantages. The question then is do you feel any need to communicate with Dublin Core?

…

On Fri, May 8, 2020 at 11:36 AM Steve Baskauf ***@***.***> wrote: A thought that I had after writing this is that perhaps it would be better to just abandon dc:type altogether and mint our own term that would be expected to have a SKOS concept as a controlled vocabulary. We could then construct the controlled vocabulary exactly as we want and express the hierarchical broader and narrower relationships clearly and exactly as we wish. That would get us out of the business of managing two separate terms (dc:type and ac:subtype). See the SKOS primer <https://www.w3.org/TR/skos-primer/#secrel> for an example involving "cats", "mammals", and "animals". One could express the type of media in the most specific way possible and the broader categories would be implied. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADQ725LODF7BUE4VQUXH73RQQKFXANCNFSM4M4FVPTA> .

[ghwhitbread]

Despite recognition of the need for refinement of the dc:type vocabulary, early initiatives within the DCMI community seemed to have fallen by the way ... nothing much happening there in the last 20 years. Maybe it is just too hard, or maybe the current DCMI recommendation to use a combination of :type and :format (. e.g. image, model/x3d-vrml) is considered adequate.

The result of the sparse vocabulary, and recommendation rather than mandate, is a plethora of vocabulary extensions with little interoperability. So I don’t believe that heading down that path with “3D resource” is a good solution.

There is the option of using dcterm:type refinement and a domain-specific vocabulary for the property, though this is obviously not popular, even if legitimate.

So, if DCMI type + format has been considered, @baskaufs suggestion to mint a new term and vocabulary would get my support ... if the tie-back to DCMI remains, either by maintaining dc:type or linking from the new vocabulary; and there is appropriate effort to ensure/establish/communicate some TDWG level of interoperability with the use of SKOS vocabularies.

[chicoreus]

It feels to me like @ghwhitbread is pointing us in the right direction. The combination of type and format is an adequate description within the broad concepts of the DCMI type vocabulary, while the 3 dimensional nature of a 3D resources adds orthogonal concern of 3 dimensionality. Consider a 3D model produced from the a CT scan of a long bone. This a StilImage (of some format, say model/x3d-vrml). Animated renderings can be made from that model with a time component that are moving images, and the model can be played in a VR environment, but fundamentally (going back to the latin), it is a still image of a static thing, motion and interaction come from renderings. Likewise consider a 3D model produced from a CT scan of two long bones in articulation, with a time element showing the normal range of motion of the joint. This is a MovingImage (of some format, perhaps, perhaps not model/x3d-vrml). Both still and moving image renderings can be made from this model. Now contemplate the 3D model of the two long bones in articulation with the physics package in a VR environment that allows two people to interact with the long bones at the same time, moving the joint and experiencing the forces on the joint. This is an InteractiveResource, that requires user interaction to understand, and may have some application/... format). Again, both still and moving image renderings can be made from this model. The 3D nature of these three cases is an underlying essential element for communicating that these are all three dimensional models of long bones (produced from CT scans) - that 3D nature could be expressed well in a separate vocabulary (where concerns might include source origin of the 3D model (e.g SAR for topography or sea surface, medical imaging scans, 3d surfaces constructed from multiple images, etc), but have expression of the dimensional nature of the model as a top level concern (which the DCMI type vocabulary does not).

[chicoreus]

To put that more concisely, a "3D resource", can be described entirely adequately with the DCMI type vocabulary as a StillImage (or MovingImage if the model (not its rendering) includes a time component), but the 3D nature is an orthogonal concern that merits its own vocabulary.

[douglasmb]

Hi all - I am the convener of the 3D Imaging Task Group and I tend to agree with the rationale about "3 dimensionality" as generally being orthagonal to the resource type. This discussion will be useful in my next meeting with the rest of the group. I just want to put two other things out there. In my understanding "format" wont sufficiently describe the resource type. Its important to differentiate 3D files that are polygonal meshes versus point clouds. However, these can be saved using the same file formats. Another issue it is essentially standard now that raw volumetric or photogrammetric datasets are saved as a file set (like a dicom series or tiff slice stack), zipped into an archive. In these cases, I dont assume specifying "zip" or "tar" as a format is going to describe very much about the dataset. So for these reasons we think a separate "subtype" vocabulary is really important. Important terms would include: "multi-file projection series, multi-file image slice series, single file image slice series, texture map, point cloud, polygonal mesh, and finally "image collection" where "image collection" would be used to reference the raw photographs underlying a photogrammetry mesh model.

[douglasmb]

we are also presuming that a new Resource Creation Vocabulary term will be necessary called "ac:captureTechnology" or "ac:captureModality" as none of the existing terms seem appropriate. ac:captureTechnique and ac:captureDevice are related but different. "ac:captureTechnology" would contain information about the scanning technology: e.g., "photogrammetry", "CT scan", "MRI scan", "Structured Light Scan", "Laser Scan" etc.

[baskaufs]

For recent activity on this issue, see tdwg/ac#243 .

For the actual proposal made to DCMI and the responses of the Usage Board, see dcmi/usage#105

[baskaufs]

This issue was discussed at a TAG meeting without any conclusive result and we concluded at the 2022-11-07 TAG working session that we should close this and let the 3D group handle this as they best see fit. At the 2022-11-10 Audubon Core Maintenance Group meeting, it was suggested that Audubon Core mint a 3D resource class term to be used as a value for dc:type and suggest to DataCite that they add it to their list of acceptable values. This proposal may be pursued independently of the rest of the 3D Task Group term proposals.