[Crm-sig] RDFS, XML and more

Robert Sanderson azaroth42 at gmail.com
Wed Sep 8 17:33:30 EEST 2021

Dear Miel, all,

On Wed, Sep 8, 2021 at 4:11 AM Miel Vander Sande via Crm-sig <
crm-sig at ics.forth.gr> wrote:

> Op di 7 sep. 2021 om 09:38 schreef Pavlos Fafalios <fafalios at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210908/5dae6a8a/attachment.html>

More information about the Crm-sig mailing list