LIST_OPERATIONS

• type
  • basic operation
• "Endpoint"
  • Server S (self=TypedPIDMaker) ("/" in REST terms)
• Output
  • Create
  • Retrieve
  • LIST_OPERATIONS?
  • other basic operations?

with FAIR DO context / endpoint:

• type
  • basic operation
• "Endpoint"
  • FAIR DO "F" ("/F" in REST terms)
• Output
  • all known operations FAIR DOs executable on "F". Known means operations which have been resolved, created, or updated with this typed PID maker instance (or has been bootstrapped at the start of the service).
  • update (no delete)
  • other basic operations?

implementation detail, needed for DOIP->FAIRDO->LIST_OPERATIONS

• name
  • checkOperationCompatibility
• Input
  • PID of (known) operation "O" (also a FAIR DO)
  • PID of (given->known) FAIR DO "F"
• Output
  • Can I execute operation "O" on FAIR DO "F"? -> boolean or error (=validation?)
• Criteria:
  • location-dependent: operation needs data lying on Zenodo, because Zenodo implements the operation.
  • type-dependent: operation requires type in F
• Pseudocode
  • if O has no operation type --> return error
  • if F has type in operation.supportedTypes --> return true
  • if F has location in operation.supportedLocations --> return true
  • otherwise return false

This operation is implicitly part of DOIP. There is a standard operation performed on a given PID to list all supported operations. Thus, any kind of complexity to determine these operations can be hidden.

I am confused about the structure of the FAIR DOs. If I do this operation on the DTR like this:

curl --request GET \
  --url 'https://dtr-test.pidconsortium.net/doip?operationId=0.DOIP%2FOp.Retrieve&targetId=21.T11148%2Fb9b76f887845e32d29f7'

I get the following response:

{
	"id": "21.T11148/b9b76f887845e32d29f7",
	"type": "KernelInformationProfile",
	"attributes": {
		"content": {
			"identifier": "21.T11148/b9b76f887845e32d29f7",
			"name": "HelmholtzKIP",
			"description": "Draft Kernel Information Profile used within the Helmholtz Metadata Incubator Platform (HMC).",
			"provenance": ...
			"expectedUses": ...
			"representationsAndSemantics": ...
			"properties": ...
		},
		"acl": {
			"writers": [
				"21.T11148/dc132326d510091661c0",
				"21.T11148/97a37cc7ae18266fd8e3"
			]
		},
		"metadata": {
			"createdOn": 1583416068915,
			"createdBy": "21.T11148/fc3224b0abc8b35bd3cb",
			"modifiedOn": 1690904854192,
			"modifiedBy": "21.T11148/dc132326d510091661c0",
			"txnId": 1690904854190390
		}
	}
}

As you can see, the data (the actual profile definition in the DTR) is in attributes.content. Reading the specification, I thought the object should be one of the elements or so, because the specification says about the attributes: "attributes (optional): one or more fields (key-value pairs) serialized as a JSON (sub) object." (Appendix A). Now I am confused what to put where.

What do you think how we should handle this? My proposal:

• The Typed PID Maker only supports retrieving the PID record metadata (it will not download and serialize actual DO data), maybe additional linked metadata records in future.
• The records key-value-pairs go into attributes, additional records maybe(?) into elements
  • using content and metadata attributes does not seem to come from the specification and also has some issues (acls, name and ID are not metadata?).
• If the user requests the element/DO data, respond with an error, as this is not supported.
  • The retrieve operation has according request parameters to specify what should be returned.

But: This is kind of different of how cordra does it, it seems.

I think the response fully fits the spec. It consists of key-value pairs which have complex values. This is also how I did it for base-repo. The keys are not further specified. If it comes to the data, the TCP-based implementation has payload streams attached. Not sure how this is covered via the Rest adapter.

But assuming my DO would be an image, wouldn't it be an element instead of an attribute? What do you think how I should do it? Is it even specification conform to re-use create (or other CRUD operations)? Because we do not input the digital objects in every sense, but only make them such by registering a PID record. Should I handle the record as if it would be the digital object itself?