Skip to content
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

Why is dctype:PhysicalObject 'inanimate'? #101

Closed
dr-shorthair opened this issue Oct 18, 2021 · 2 comments
Closed

Why is dctype:PhysicalObject 'inanimate'? #101

dr-shorthair opened this issue Oct 18, 2021 · 2 comments

Comments

@dr-shorthair
Copy link

dr-shorthair commented Oct 18, 2021

Current definition:

  • An inanimate, three-dimensional object or substance.

This would appear to limit the applications of DC.
What DC Type should be used for descriptions of living things?

(Asking for my friends over in the Darwin Core community, who are trying to clean up the definition for samples and specimens.)

@tombaker
Copy link
Collaborator

@dr-shorthair Thank you for raising this interesting issue!

Some history: The DCMI Type Vocabulary goes back to a 1999 proposal from Rebecca Guenther that is still available on the LC website. It is interesting to note that, as originally defined in the first draft, a physical object was "a non-human object or substance. This category includes objects that do not fit into any of the other categories on this list". As originally proposed, "DC-Type" was a "qualifier" for qualifying the Type element. Prior to the use of URIs as term identifiers, it was intended as a keyword for giving context to a text value such as the string "physical object".

In 2000, it was approved as an Element Encoding Scheme but eventually evolved into the Vocabulary Encoding Scheme DCMIType and defined as "the set of classes specified by the DCMI Type Vocabulary". (One can think of the URI of a Vocabulary Encoding Scheme as being like the concept scheme URI of a SKOS concept scheme.)

Looking at DCMI Metadata Terms today, one might question whether the classes of the DCMI Type Vocabulary are substantially different from the classes defined in the /terms/ namespace. Classes such as "Agent" and "LicenseDocument" might just as well be used as the value of dcterms:type (or indeed rdf:type) assertions as "Collection" or "Dataset".

It is in this spirit that I point out the definition of dcterms:PhysicalResource: "A material thing". I'd argue that an organism is a material thing.

I'm curious whether this would fix the DWC issue or, if not, whether it were because users see a significant distinction between classes defined in /terms/ as opposed to /dcmitype/.

@tombaker
Copy link
Collaborator

We note that discussion continues on an open issue in the DWC community but see no need for further discussion in the Usage Board. Closing...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants