Hi Robert,

That makes a lot of sense. If you were to only support a subset, you'd need to accompagny it with a SHACL profile to indicate what shape the context offers and to make sure that things don't go missing. Although in practice, this might indeed create chaos rather than prevent it.



Op wo 8 sep. 2021 om 16:33 schreef Robert Sanderson <azaroth42@gmail.com>:

Dear Miel, all,

On Wed, Sep 8, 2021 at 4:11 AM Miel Vander Sande via Crm-sig <crm-sig@ics.forth.gr> wrote:
Op di 7 sep. 2021 om 09:38 schreef Pavlos Fafalios <fafalios@ics.forth.gr>:
Having a JSON-LDĀ serialization seems useful, given the increasing adoption of this encoding format. We can start considering its implementation once the RDFS is approved by CRM SIG.Ā 

When done right, it can make complex models like CIDOC-CRM look a lot less scary. I think the goal should not be a complete implementation of CIDOC-CRM in a single context, but rather lead to an entry-level format that can be expanded when necessary (json-ld allows you to do this). I'm working on similar examples for PREMIS OWL.

I agree that a well crafted context can greatly improve usability of the ontology in modern software frameworks. This has been demonstrated very clearly in different domains since the standardization of JSON-LD 1.0 in 2014. I'm very happy to put as much effort as needed into this.

However, I disagree about the goal. I feel that the SIG should provide a context that covers the same set of classes and predicates as in the RDFS. Composing multiple contexts together with no overlap would be extremely error-prone, with little way to detect those errors. For Linked Art, we started with two contexts ... the terms that we recommend from CRM in the profile, and the second was all the other terms. If you wanted to stick with just Linked Art, you imported one. If you wanted to use anything extra, you also imported the rest. And even that level of composition was highly frustrating for implementation, as you needed to know all of the terms used in the document in order to know whether you should use one or both. The easy solution was to always use both... defeating the purpose of splitting them.

And the errors are difficult to detect because if a key in JSON-LD doesn't match an entry in an included context, it is silently ignored. So data would just disappear, and you had to go hunting through other people's documents (the contexts) to figure out why.

By sticking to the same divisions as the RDFS files (e.g. one context for base, one for sci, one for geo, etc) it would be straightforward to manage from a publishing and consumption perspective at the ontology level, rather than at an application profile level.