[multimeric]

Closes #466.

I don't love introducing a new section as the spec is already quite long and complex, but I can't think of anywhere else that suits this better. Open to suggestions though.

[elichad]

happy with the text, would like a second opinion from @stain @ptsefton (as editors) and/or @simleo (as tool maintainer) on whether you would be fine with this being added to 1.3 - in my view this is a clarification rather than introducing new behaviour.

[ptsefton]

It is good to cover this issue as it has been left implicit, and we do use CURIEs in the LDaCA context but only for property key and @types. The Javascript RO-Crate library deals with resolving these IDs when it needs to, but does NOT do the same for entity @ids, and I suspect other libraries that don't immediately parse the data as RDF would be in the same boat, typially the approach would be to build an index of raw @ids as found. It would be important to have this implemented place before we start encouraging people to use it.

(This is one of a cluster of issues we need to cover in v2.0 spec as well to give much more explicit advice about how to implement a core set of valid JSON-LD behvaiours without handing it to an RDF-based tool, for example I think a lot of people are relying on order-presevation in arrays ATM which is a wrong assumption about JSON-LD but is very useful)

[multimeric]

Fortunately I think CURIEs can be treated as regular keys and values by the non-RDF parsers, so I don't think this should break anything.

[multimeric]

in my view this is a clarification rather than introducing new behaviour.

@elichad does that mean I apply the patch to docs/_specification/1.3/appendix/jsonld.md instead? Are you other reviewers happy with this change?

[ptsefton]

There's a potential issue with the same ID appearing with and without a CURIE though

[multimeric]

There's a potential issue with the same ID appearing with and without a CURIE though

The same applies for type and predicate IRIs in theory. Maybe we should just say that each IRI SHOULD only have one representation in the crate, to facilitate RDF-ignorant parsers?

[simleo]

Fortunately I think CURIEs can be treated as regular keys and values by the non-RDF parsers, so I don't think this should break anything.

I've checked it does not break ro-crate-py.

There's a potential issue with the same ID appearing with and without a CURIE though

The same applies for type and predicate IRIs in theory. Maybe we should just say that each IRI SHOULD only have one representation in the crate, to facilitate RDF-ignorant parsers?

Sounds good to me.

[stain]

I think this is good for 1.3, it's in an appendix.

However I disagree with allowing CURIEs in @id as it would break clients who are not processing as JSON-LD and would make it hard to follow URLs that are no longer URLs. So I've modified the text for that, as well as to not generally use the schema: prefix.

[multimeric]

Thanks @stain. I omitted the RO-Crate context just for concision like I did the required entities. It is a challenge making really small examples while meeting all the requirements.

However I disagree with allowing CURIEs in @id as it would break clients who are not processing as JSON-LD and would make it hard to follow URLs that are no longer URL

Is this because they don't "look" like URLs? Or is your concern that it will allow multiple representations of the same IRI? Because as I said above, I'm happy to enforce that each IRI has only one representation (which might be a CURIE)

[simleo]

The current version looks good to me.