Data Provenance (DPS) TC

Hi,

I think terse is not a goal in itself and we can focus on the
semantics of what these workproducts deliver.

Looking around docs.oasis-open.org it seems that every TC also defines
a namespace for itself. Within that namespace (our workproducts) are
free to be chosen semantically, i.e. in my understanding we do not and
should not place our TC name into the abbreviation as the
example from the CACAO TC shows:

- https://docs.oasis-open.org/cacao/layout-extension/v1.0/layout-extension-v1.0.html

I imagine workproducts always within a taxonomy / hierarchie
like:

OASIS:
DPS TC:
use-cases: workproduct so and so
data-provenance:
prose: some markdown source et al.
schema:
abnf: some made up ABNF grammar
json: some set of JSON files
xml: some set of XML files
yaml: some set of YAML files

or the JSON equivalent:

{
"OASIS": {
"DPS TC": {
"use-cases": "workproduct so and so",
"data-provenance": {
"prose": "some markdown source et al.",
"schema": {
"abnf": "some made up ABNF grammar",
"json": "some set of JSON files",
"xml": "some set of XML files",
"yaml": "some set of YAML files"
}
}
}
}
}

So, we could name the initial use cases simply "use-cases-v1.0"
and the prose workproduct describing the data provenance schema
as "data-provenance-v1.0".

Currently the oasis-open.org website proper is suffering of HTTP/504
gateway timeout, so I cannot look up if there is still the
document I think originarlly created by Robin Cover or something
similar available that provides guidance in such matters.

PS: Maybe we want to start with v1.1 or v2.0 depending on
how much and severly we change the contributed schema / concept.
Esp as we will be named data-provenance-... there could be
mixups when we also create a v1.0 and the data and trust alliance
already has a v1.0 or a data-provenance schema in the wild.

Cheers,
Stefan.