Mapping from CDIF metadata to RDA PID Kernel attributes

In the Fair Digital Object Framework (FDOF) specifies that a Digital Object idnetifier (PID) can be resolved to obtain a PID kernel record. For the content of the PID kernel record we are following the RDA Recommendation on PID Kernel Information (Weigel et al, 2019 ). The implementation approach for supplying PID Kernel information records (See sections 3.1 and 3.2 in https://fairdigitalobjectframework.org/) associated with digital object identifiers is an architecture decision, not specified in this version of the CDIF framework. However, the information necessary to produce such metadata to implement the FDOF conventions is included in the CDIF metadata implementation, except for embedding of thumbnails or other data objects directly in the metadata digital object.

FDO field	CDIF schema.org	Scope Notes
FDO Creator	“creator” : [{Person or Organization}, …]	Agent responsible for creating the FDO (and implicitly issuing the FDO PID) [NOTE– creator of content and identifier registration are not necessarily the same agent]
FDO Responsible Organisation (Resource)	“provider”:{Person or Organization}	note that this can be another organisation than the PID issuer. If the agent is an organization, the value is taken from the ROR registry value domain (or other with namespace id). Implement as responsible part with an Agent (name, ID, contactInformation)
RDA checksum	“spdx:checksum”:	Checksum of object contents. Checksum format is determined via the attribute type referenced in a Kernel Information record. Called etag in PubCom-PR-PIDProfileAttributes-2.0. The algorithm for checksum calculation should be defined in the definition of the object type, or described in the resource description in this metadata. spdx value is an object with ‘algorthm’ and ‘checksumValue’.
FDOF digitalObject-Mutability	“publishingPrinciples”:	This attribute indicates whether the included bit-sequence is mutable or immutable, and policies for when new version is created when some bits are changed. Principles apply at the DigitalObject/Distribution level.
FDOF Persistency-Policy	“publishingPrinciples”:	this attribute indicates what the intention of its creator is with respect to its life-time/maintenance; the value domain is a vocabulary like: {UNKNOWN, NONE, Years , or EarthCube ELT } (note: seems only partly covered by RDA digitalObjectPolicy.
RDA digitalObject-Policy	“publishingPrinciples”:	Pointer to a policy object that documents changes to the object or its Kernel Information record, including object access and modification policies. A caller should be able to determine the expected future changes to the object from the policy, which are based on managed processes the object owner maintains.
FDOF Responsible-Organisation (Technical Management)	“contributor”: {“@type”: “Role”, “roleName”: “maintainer”, ”contributor”: {“@type”: “Organization”,   “@id”: {personID},  “name”: {personName}, ..other possible properties omitted } }	after creation, the same or another organisation will be responsible for further management of the FDO. The Responsible Organisation equals the FDO Creator if available by default (mandatory attribute) [equate with Resource point of contact]
FDOF rightsRecord	“license”:{text or URI}Or ”conditionsOfAccess”:{text or URI}	This is a pointer to a resource that specifies access permissions. Include: FDOF licenceConditions: that links to one or more formal specifications about licences such as CC-x; FDOF transactionRecord: a resource that includes contractual information.
FDOF ScientificDomain	“keywords”:[{string} or schema:DefinedTerm]	indicator of the scientific domain the FDO refers to. This ensures compliance with the FAIR principles, which are per definition applicable at the domain level. This attribute is required since different mandatory attributes may be required at the domain-level.
Profile	“subjectOf”/”dcterms:conformsTo”: {identifier}	The Kernel metadata profile is a schema that determines the attribute requirements for FDO metadata beyond the base requirements. In the FDO world, the kernel profile specifies Kernel information about the resource associated with an identifier. Schema.org does not have a ‘conformTo’ property so follow DCAT v3 using the Dublin Core Terms property.
FDOF digitalObjectType	“@type”:{schema.org type}	The kind of resource associated with an identifier. The type implies a schema that dictates the format, information model, and profile conventions for the resource representation contained in the identified digital object. Use appropriate Schema.org type for @type property, the additional type should be from a controlled vocabulary.
	“additionalType”:[{schema:DefinedTerm or URI}, …]	Expect to use a CDIF recommended vocabulary here
RDA dateCreated	“datePublished”: {date time}	Date (and optional time) the Digital object was created
RDA dateModified	“dateModified” : {date time}	If the DO bit sequence is mutable, specify the last date/time of object modification. Must be consistent with etag and current version number.
RDA version	“version” : {string}	If tracked, a version for the object, which must follow a total order. Mandatory for all objects with at least one predecessor version.
RDA digitalObjectLocation	“url”:{URL}	If the FDO has a digital representation, it is mandatory that the PID record specifies the location where the FDO can be retrieved, either as an URL or a PID. This is URL in a metadata record for which the target resource is a digital object, or the contentURL or accessURL if the target resource is a non-digital object with one or more distribution representations. Since FDO PID identifies a digital object, there is only one distribution,so use the simple schema:url.
FDOF operationInfo	Not implemented by CDIF v1.0	Some communities want to include a payload information such as a thumbnail image in the case of DiSSCo’s Digital Enhanced Specimen FDO.