Attempt to clarify Attached vs Detatched #381

[ptsefton]

This is an attempt to better define the difference between Attached and Detached and to provide advice to implemeters like @simleo. I have been working in parallel on some ideas for how to better structure the spec for RO-Crate 2.0 and some of the ideas from that work have made their way in here.

The main part of this is the structure.md file, and the data-entities.md file but I have also updated the terminology

This was intended a smallish suggestion to see what people thought that got a bit out of hand -- there is still some work to do if people like this idea.

Main changes:

• Introduce a new concept which is the Valid RO-Crate Metadata Object - that is a metadata file that has been successfully parsed and has all the basics @context, @graph, and a Root Data Entity -- a library could stop here and be used by Validators / Profile Validators that deal with metadata and semantics
• Add a formal conformsTo applied to the Root Data Entity to indicate conformance with the basic metadata stuff ie what's in the root-data-entity.md file -- this opens a way for people to use the basic structure other purposes. ATM this is still part of the spec but for 2.0 I think we could pull it all out into a profile.
• Define Attached RO-Crate Package and Detached RO-Crate Package
• Define a new mechanism
• Allow Attached Packages to have URI @ids (which is kind of allowed but the spec was a bit ambiguous) I feel strongly about this having worked with lots of real world data we want to distribute.

This paves the way for making things more modular in future - a small, strict spec about what an RO-Crate file looks like and move all the metadata stuff to a profile and a lot of other stuff about best practice linked data etc into a set of guidelines. We will need to work on making formal definition of profiles stronger and alllow for multiple implementations.

[elichad]

Extra comments after today's community call:

Need to do a close read of this (having skimmed it already actually, looks like there are plenty of changes since last time I looked), and what I want to check is is that the initial definitions of attached/detached that people have already been working from aren't changed massively at this late stage. But also, perhaps more importantly, the terms should reflect the current state of how RO-Crate is used - I don't think it makes much sense for us to be building crates that violate a spec we've just released.

I do think it's worth having something about this in the spec rather than removing it altogether (unless we cannot come to an agreement on the definitions). I've found it's fairly common for people to think they can't do anything "detached" when they're new to RO-Crate (or only familiar with 1.1), and having these terms defined makes the concepts/patterns easier to discuss. Plus it will ensure we always consider the different types of crate when adding new things to the spec.

In the longer term, these terms probably belong in a guides/patterns section, rather than in the core ruleset (unless they are particularly useful for all the IF/ELSE bits that crop up when handling data entities).

[simleo]

This code snippet has been probably pasted by mistake.

[ptsefton]

Fixed - so sorry I was rushing to commit before the meeting yesterday

[ptsefton]

I have taken on board feedback from @simleo -- this is too many changes. I will work on a simpler version of this that does not introduce new terms and defines Attached and Detached as essentially processing modes and does not telegraph changes that may or may not come in a v2.

Will do a separate PR today.