[Crm-sig] RDFS, XML and more
Miel Vander Sande
miel.vandersande at meemoo.be
Thu Sep 9 13:10:51 EEST 2021
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 at gmail.com>:
> 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...
More information about the Crm-sig