It would be a great enhancement, if the configuration of a transformation could follow a standard, most preferably and RDF ontology.
The current data model for transformation setup is described in the OpenAPI specs as the TransformationInfo scheme. See https://github.com/SCDH/seed-xc/blob/main/api/src/main/resources/openapi/seed-xc-openapi.yaml#L420
At the moment, it obviously has traces of describing XSLT transformations. This should be abstracted away, at least.
On the long run we want to use the transformation ID, that links to a TransformationRecord be a RDF URI, that identifies a representation type––i.e. not a representation of a resource, but a recipe to how to create such a representation. This URI can then be used as a profile identifier as described in https://www.w3.org/TR/2023/WD-dx-prof-conneg-20231002/#profileid
This would lead to a LOD description of resources, their representation and how their representations are derived from each other.
It would be a great enhancement, if the configuration of a transformation could follow a standard, most preferably and RDF ontology.
The current data model for transformation setup is described in the OpenAPI specs as the
TransformationInfoscheme. See https://github.com/SCDH/seed-xc/blob/main/api/src/main/resources/openapi/seed-xc-openapi.yaml#L420At the moment, it obviously has traces of describing XSLT transformations. This should be abstracted away, at least.
On the long run we want to use the transformation ID, that links to a
TransformationRecordbe a RDF URI, that identifies a representation type––i.e. not a representation of a resource, but a recipe to how to create such a representation. This URI can then be used as a profile identifier as described in https://www.w3.org/TR/2023/WD-dx-prof-conneg-20231002/#profileidThis would lead to a LOD description of resources, their representation and how their representations are derived from each other.