Clarify the role of context, keys and IRIs

[ptsefton]

@elichad has pointed out some ambiguity in behaviour of RO-Crates related to context.

I'm just putting some thoughts here for future discussion.

Consider a crate where the key licence (with a c) is mapped to https://schema.org/license (with an s) by over-riding the default RO-Crate context.

When validating this, some code that I wrote in the Javascript library where it is asumming an RO-Crate context and looking for the key license will return an error (crate does not have a license) whereas SHACL validators and the new RO-Crate-MASP project both validate using the IRIs. This is an issue that we need to address explicitly in RO-Crate 2.

We could say that an official RO-Crate context must be present and that keys may not be redefined by subsequent other contexts. If we do this would this extend to all of Schema.org or jsut things that are defined specifically in the RO-Crate spec and then check that both the key and the resolved IRI are correct or we could express the spec in terms of IRIS and allow people to use whatever context they choose - forcing all libraries to have fully JSON-LD compliant context resolution (which I don't think is generally the case ATM).

If we decide that the key AND the URI must be as per a specific context then this is easily supported, at least in the RO-Crate-MASP prototype where we can spefify an rdfs:label property, and check that at validation time. Noting here also that experience with the Language Data Commons project has taught us that for our language-data schema it is better to refer to all terms using a prefix, like ldac:linguisticGenre - I'm not sure if that's OK to put in an rdfs:label property

We could also allow for contexts with keys in languages other than English to be defined as RO-Crate contexts.