Provenance does it modify description?

[HughP]

I have a question about the DCT namespaced term "provenance". It seems to not attached to a dublin core element as a modifier. That is, it seems to stand alone and directly apply to the object being described. Why is it not a modifier of "dc.description" in like manner to "dc.description.abstract" ? From a causal reading it seems that abstract is a special type of description, and a provenance is also a special type of description.

[tombaker]

@HughP I had missed this issue until just now. Thank you for the suggestion!

The set of DCMI properties and classes is modeled in conformance with the RDF data model (eg, with subproperty and subclass relations), so we do not think of properties as having the function of modifiers. So to translate your point into our model, I think you are suggesting that abstract and provenance should be considered subproperties of description.

This is an interesting proposal. @kcoyle has given some thought to the overall structure of DCMI Metadata Terms and may have an opinion on this.

As an aside, it is worth noting that in the late 1990s, a significant part of the DC community did see some elements as modifiers of others, in the manner of adjectives. In those years, if I correctly recall, there was a strong preference by many for a flat set of elements. For example, creator was at some point declared to be a subproperty of contributor - a decision considered controversial by some, who asked whether this meant that the Dublin Core now only had fourteen properties.

[kcoyle]

I see provenance and description as being quite different. Description is a description of the content of the resource itself. It is supplied by the cataloger, so it isn't an abstract, which is generally on the article and written by the author. Provenance is literally "where it came from" so it doesn't say anything directly about the content of the resource. I have been trying some categorizations of DC terms, and hadn't included a category for administration metadata. It does seem that provenance would fit into that. I'll take a look at my draft with this in mind.

[HughP]

@kcoyle I'm keen to see a written expression of your thoughts on this... maybe a blog post? I easily see how the broad category of administrative metadata can fit within the scope provenance, but some objects have a history prior to their curation by their current or first known stewards. This part of the narrative, seems to be closer to description, and also be classifiable as provenance. If we take the cultural heritage perspective on a DCMIType PhysicalObject (for example a B-29) part of its history (context) seems to fit within its description, Yet some of this is certainly provenance and may not qualify as administrative metadata.

My work with Schema.org pushed me to think more broadly about "abstract" than just print media. (For reference see: https://schema.org/abstract and the thereon linked github issue). That is, for each of the DCMITypes what does an abstract look like? Is a trailer an abstract of a movie?

[sruehle]

In the DDB we use dcterms:provenance als @HughP describes above - to describe the history of Old Books. And when you look into library catalogues you find a lot of provenance descriptions that are plain text. Looking at this the use of dcterms:provenance as a subproperty of dcterms:description or dc:description would make sense. On the other hand dcterms:provenance should be used with a dcterms:ProvenanceStatement as value, that is well structured metadata, that links to Agent, Place and Time of a provenenace event, while description - in my opinion - is about plain text describing something. To relate these two feels kind of weird.

[HughP]

@sruehle
You make an interesting recommendation:

dcterms:provenance should be used with a dcterms:ProvenanceStatement as value, that is well structured metadata, that links to Agent, Place and Time of a provenance event

I am confused though, how can dcterms:ProvenanceStatement be expressed as a class in OAI-PMH based implementations of DCMS? Do you have any examples of what the XML might look like? My limited understanding of DCMS is that only properties have values...