Motivation
I am currently working on metadata extraction from PMD/PMDco-based RDF artifacts for publication workflows, especially for Dataportal and Zenodo publication via praeco.
The immediate use case is: given a semantic asset, e.g. an instantiated rdflib.Graph or a Turtle serialization, software should be able to harvest as much publication metadata as possible automatically:
- title
- description
- creators/contributors
- license/rights
- DOI or other persistent identifiers
- version
- language
- related identifiers
- resource/distribution links
- provenance/source information
PMDco already provides a strong MSE domain model, especially around materials, processes, data items, devices, qualities, and information content entities. However, for publication tooling it is still difficult to know which node in a graph is the citable publication unit and which triples should be interpreted as publication metadata rather than domain facts.
Proposal
I would like to propose adding a small, explicit PMD publication metadata profile rather than expanding PMDco with many new publication-specific classes.
The goal would be to define a recommended pattern for citable semantic assets that reuses existing standards wherever possible, for example:
- DC / DCTERMS
- DCAT
- DataCite-style identifiers
- schema.org
- PROV-O where applicable
- BFO/RO/IAO-compatible PMDco v3 modelling patterns
Concretely, the profile could define or document:
-
How to identify the citable artifact root
- e.g. the RDF graph, semantic dataset, publication package, file data item, or distribution that should be harvested for publication metadata.
-
Which predicates should be used for bibliographic metadata
- title
- description
- creators
- contributors
- publisher/contact
- license/rights
- version
- citation
- DOI and other identifiers
- related identifiers
-
How to distinguish scientific/domain roles from publication roles
- e.g. operator, instrument owner, project participant, data curator, publication creator, publisher, funder, rights holder.
-
How to model resources and distributions
- RDF graph
- original CSV/data files
- generated metadata files
- external resource URLs
- file formats and media types
-
How provenance should connect to publication metadata in PMDco v3
- especially since PMDco 2.x used PROV-O patterns while PMDco 3.x is BFO-based.
-
A SHACL shape or validation profile
- A practical SHACL shape would be especially helpful for tooling.
- Required/recommended fields could be validated before upload to Dataportal, Zenodo, MatPortal, or other repositories.
Why this would help
This would make PMDco-based RDF artifacts much easier to publish and reuse.
It would also reduce the amount of project-specific heuristic code needed in downstream tools. For example, praeco could implement deterministic metadata harvesting instead of guessing whether a dc:title belongs to the citable dataset, a CSVW column, an ontology, or a domain object.
This would also support better interoperability with Dataportal, Zenodo, MatPortal, and other RDM/catalog systems.
Suggested direction
My preference would be:
- keep PMDco focused on MSE semantics,
- reuse established publication/catalog vocabularies,
- add a small PMD-specific profile/pattern for connecting the MSE graph to publication metadata,
- provide a SHACL shape and example graph.
Offer to contribute
I am happy to help implement this to the extent of my abilities in semantics.
In particular, I could contribute:
- an initial example Turtle pattern based on existing PMDco 2.x / PMDco 3.x data,
- a first SHACL shape proposal,
- documentation/examples for publication metadata harvesting,
- follow-up PRs once the preferred modelling direction is agreed on.
My immediate downstream use case is implementing RDF metadata harvesting in praeco, but I think the same profile would be useful more broadly for PMD publication workflows.
Motivation
I am currently working on metadata extraction from PMD/PMDco-based RDF artifacts for publication workflows, especially for Dataportal and Zenodo publication via praeco.
The immediate use case is: given a semantic asset, e.g. an instantiated
rdflib.Graphor a Turtle serialization, software should be able to harvest as much publication metadata as possible automatically:PMDco already provides a strong MSE domain model, especially around materials, processes, data items, devices, qualities, and information content entities. However, for publication tooling it is still difficult to know which node in a graph is the citable publication unit and which triples should be interpreted as publication metadata rather than domain facts.
Proposal
I would like to propose adding a small, explicit PMD publication metadata profile rather than expanding PMDco with many new publication-specific classes.
The goal would be to define a recommended pattern for citable semantic assets that reuses existing standards wherever possible, for example:
Concretely, the profile could define or document:
How to identify the citable artifact root
Which predicates should be used for bibliographic metadata
How to distinguish scientific/domain roles from publication roles
How to model resources and distributions
How provenance should connect to publication metadata in PMDco v3
A SHACL shape or validation profile
Why this would help
This would make PMDco-based RDF artifacts much easier to publish and reuse.
It would also reduce the amount of project-specific heuristic code needed in downstream tools. For example,
praecocould implement deterministic metadata harvesting instead of guessing whether adc:titlebelongs to the citable dataset, a CSVW column, an ontology, or a domain object.This would also support better interoperability with Dataportal, Zenodo, MatPortal, and other RDM/catalog systems.
Suggested direction
My preference would be:
Offer to contribute
I am happy to help implement this to the extent of my abilities in semantics.
In particular, I could contribute:
My immediate downstream use case is implementing RDF metadata harvesting in
praeco, but I think the same profile would be useful more broadly for PMD publication workflows.