Add namespace for GPG crates

[JLoveUOA]

Add terms for classes and properties for GPG encrypted crates.

draft profile describing their use can be found here: https://uoa-eresearch.github.io/GPG-ro-crate-profile/
Once profile is finalized and assigned a DOI readme will be updated.

[stain]

Looks promising!

Would it make sense to use namespace openpgp to match https://www.rfc-editor.org/rfc/rfc9580.html rather than gpg which is software from GNU that implement OpenPGP? The details you have don't seem GPG-specific.

The mapping for recipientOf in the context to https://w3id.org/ro/terms/gpg#EncryptedGraphMessage should match the key in the URI after # e.g. https://w3id.org/ro/terms/gpg#recipientOf

I would rename recipient to avoid confusion with https://schema.org/recipient -- perhaps encryptedTo or encryptedFor would work? Consider then if recipientOf should be renamed to match. Alternatively use schema.org recipient directly without adding to roterms (we don't have a way in the CSV to indicate extension of schema.org domainIncludes)

When do you need recipientOf? It can cause inconsistency to have both direct and inverse property but sometimes they are good. We use schema.org inverses sometimes in RO-Crate when needing to refer to external things e.g. subjectOf (starting from a contextual entity to a CreativeWork which is not part of the crate) vs about (typically from a CreativeWork data entity to a contextual entity).

[JLoveUOA]

Thanks @stain.

very good point regarding openpgp vs gpg, our implementation makes use of gpg for key management however for wider use there's no reason to restrict the profile or terms in that way.

Updated recipients to "encryptedTo", this was a bit of a hangover from trying to stick as closely to schema.org as possible. Having them separate is nice to reduce ambiguity.

As for recipientOf I've left it as an option renamed to encryptedFor, I've found an inverse can have some situational use for tracking if a message that a person/organization should be able to decrypt is missing or hasn't been decrypted, for instance if a key is invalid or expired and/or if they've fallen off the encryptedMessage's recipient (encryptedTo) list. it's a bit of belt-and-bracers approach to be 100% sure we are re-encrypting to all key-holders that we only considered for situations like rotating keys/re-encrypting.
In the profile it's a MAY, I don't really expect it to be used in most cases but nice to have just in case.