Finding the root data entity without knowing crate version.

[Pfeil]

Hi,

I am currently working on adding support for the first features of the 1.2-DRAFT to ro-crate-java. I start by supporting "conformsTo" to be an array (or not) when reading the crate. If I understand it correctly, this is a specific feature of 1.2.

I hope I did not just miss the part in the specification that explains my question:

I also saw that the "finding the root data entity" algorithm changed. I think this change makes a lot of sense, but now I wonder how to handle the fact that when reading a crate, I do not know which algorithm should be applied. My questions are:

• Is the new finding algorithm considered to be backwards compatible, so I can apply it for crates of version 1.1? If the answer is no, should I implement both approaches, run the newest one first, let it fail if it detects that it is not responsible for this version, and then fall back to the previous algorithm?
• The new algorithm is missing the part where you would check for the prefix "https://w3id.org/ro/crate/", but I think it would be needed if conformsTo is an array as mentioned in the profile chapter. Should I do it this way? (this might be worth a bug report?)
• I see there is a changelog and a milestone, but it is still kind of hard (in terms of time intensive) to get a rough overview about the changes, making it harder to plan architecture changes. Is there some additional guidance available or planned?

[stain]

Sorry this is an old question.. could you check if algorithm in https://www.researchobject.org/ro-crate/specification/1.2-DRAFT/root-data-entity.html#finding-the-root-data-entity is now clearer?

The algorithm would be backward compatible to 1.1 as there was no way to rename ro-crate-metadata.json entity in 1.1, however older versions 1.0 could have ro-crate-metadata.jsonld which would fail the 1.2 algorithm. Would you consider that a breaking change?

I would try 1.1 algorithm first, then revert to 1.0 algorithm which should also find 0.2.

Do you think we need a note in 1.2 (#353) about the backward compatibility and other algorithms?

[Pfeil]

Hi Stian, sorry for the late response. This is an old question indeed. It took me a while to get what my question was. I should have pointed it out more clearly. Just for documentation, as I needed to point it out to myself anyway:

The difference (before the current change) between the algorithms was only step 2. This was step 2 in v1.1:

2. ..if the conformsTo property is a URI that starts with https://w3id.org/ro/crate/

And this was step 2 in v1.2-DRAFT at the time I was writing my question:

2. .. if the `@id` is `ro-crate-metadata.json`

---

Ok now to your anwer:

Sorry this is an old question.. could you check if algorithm in https://www.researchobject.org/ro-crate/specification/1.2-DRAFT/root-data-entity.html#finding-the-root-data-entity is now clearer?

I am relieved that you were able to track down this issue to something that actually could happen, because my question was more general about compatibility. I think the algorithm is fine to fix this, yes.

The algorithm would be backward compatible to 1.1 as there was no way to rename ro-crate-metadata.json entity in 1.1, however older versions 1.0 could have ro-crate-metadata.jsonld which would fail the 1.2 algorithm. Would you consider that a breaking change?

I'd consider it a breaking change if the algorithm would not consider it, yes. But the new one is totally fine. I plan to update ro-crate-java soon.

I would try 1.1 algorithm first, then revert to 1.0 algorithm which should also find 0.2.

So in general, try the newest versions first, and if they fail, go downwards? This is what I plan to do, with the exception that, as v1.2-DRAFT is not yet stable, I first try v1.1, currently. But I plan to switch as soon as v1.2 is out and supported in our implementation.

My core question was, I believe, supposed to be about point 2 of my list above: The step 2 of v1.1 may be incompatible with v1.2 crates (forward-compatibility). This is because the conformsTo value may be an array. And I wanted to know

• if this was done intentionally (just asking as long as it is still a draft),
• if we should also use the new algorithm for the old crates or try using the ones of the specific version somehow (this has been cleared),
• and in general, if there are other hints from you or other developers to share, for implementations.
  • I am not sure if it did back then, but I see the changelog marks some points as "change", which I think also means a "breaking change" here. This is really helpful, and I have no idea if this was available in beforehand. I am not sure if I can check all changes (semi-)programmatically within the library (I'd love to provide upgrades for crates to newer versions), but I guess in some cases we can't really change this.