Align manifest.json with RO-Lite work

[stain]

Hi, in @kylechard asked me to have a look at this, as in RO-Lite we are trying to formalize exactly what you are trying to do.

This patch is aligning the manifest.json closer to https://researchobject.github.io/ro-lite/0.1.0/ draft but without the suggested relocation it to /manifest.jsonld so that this is still valid according to existing BDBag.

• Description typo -> description (for http://schema.org/description)
• Use http://schema.org/ context, avoids "@type": "@id" mapping and schema: prefix
• Modified license (as we're not so interested in license of the license file) - express on the overall RO
• Use schema.org over foaf
• schema.org JSON-LD blocks can be used directly as in examples
• Fixed missing URI escaping in folder (good example!)
• Fixed @id of the person so it's an actual URI - here using ORCID (as in RO-lite directly rather than with orcid property)
• http://schema.org/keywords instead of http://schema.org/category as category does not apply to http://schema.org/CreativeWork (alternative: relate it to https://schema.org/exampleOfWork if there's something it's an example of)
• http://schema.org/creator http://schema.org/createdDate instead of pav:createdBy and pav:createdDate
• Use http://schema.org/dataset as main holder, which makes the ro:ResearchObject also be a http://schema.org/DataCatalog and implicit @type: Dataset
• "duplicate" dataset relation in aggregate so that the doi Dataset instance is also part of the RO

Try the JSON-LD in https://json-ld.org/playground/ and click Table to check the triples are in the correct namespaces etc.

https://search.google.com/structured-data/testing-tool is not ideal as it gets upset on properties from non-schema.org vocabularies (which are harmless according to @danbri) - but at least it flags mistakes like Description vs description

In the RO-Lite work we want to move towards formalizing this approach, so we would likely make a new JSON-LD context to avoids the tricky "@context: [...]" hacks above.

If you are interested you can join ResearchObject/ro-crate#1 and help us shape RO Lite.

Alternative 1 - all schema.org: https://gist.github.com/stain/2673f4c920a86d1b257cc0a696b32df4 (RO and bdbag tools does not know this yet)
Alternative 2 - schema: prefix only: https://gist.github.com/stain/93686e8e557f13e8edccc15a767e8499 (works just as well in https://search.google.com/structured-data/testing-tool - but JSON looks more noisy as schema: properties become more "imported"

This patch is a "middle ground" of those two approaches, preserving in particular the OAI-ORE aggregation aspect of research objects.

[craig-willis]

/cc @ThomasThelen @Xarthisius

Thanks much @stain, this is quite helpful. We are very close to a release candidate with a first implementation, so this will have an immediate impact.

"duplicate" dataset relation in aggregate so that the doi Dataset instance is also part of the RO

In this example, the RO is only using a single file from within the dataset represented by the DOI, as indicated by isPartOf. Why do we also need to include the doi for the full dataset?

[Xarthisius]

• Fixed missing URI escaping in folder (good example!)

I'm strongly opposed to this change. Why would we urlescape something that's never used in an actual url...? If there's a valid reason, what else should be escaped?

[stain]

Specification RO-Crate 1.0 now released.

I've added an explanation on the URIs, see new JSON-LD section