Re: [dxwg] JSON-LD context missing as a canonical resource and duplicated in-line in examples (#1428)

> > > It is unfortunate that JSON doesn't allow comments.
> > 
> > 
> > Sounds like a glaring omission to me. JSON files will be very hard to maintain over time.
> 
> JSON is not designed to be a language for configuration files or long-term documents maintained by humans. However you could add a `'comment:'` key anywhere you want, because most JSON consumers ignore keys that they are not looking for.

I agree, for me json-ld is an aid for a developer, bridging the data semantics world and the software developer world. Actually if the URIs used are all dereferenceable then they will point the user to the intended semantics. Furthermore,  a json-ld context is bound to a data exchange, and not to a W3C spec, like DCAT. I can write perfectly a json in german and map it to DCAT, resulting is a fully conform, semantically unambiguous DCAT based exchange. 

In my experience json-ld contexts need only explanation when the distance between the json representation and the semantic representation is too far. In those case comments are helpful to explain why this or that mapping has been used. But that is at implementation level. 
Here at the w3c DCAT specification level the json-ld context should be trivial, not over-engineered. But for me, only one quality level should be guaranteed: namely 100% backed-up with firm URIs. (I have seen communities that just do json-ld like XML: using none resolvable domains, defeating thus the purpose for using json-ld for me.)  
If complex json-ld mappings are required, then this is maybe a use-case for that community rather than for this.

I think we should as DCAT specification not try to design any representation support to be used directly in an operational system. This is better done by contributing to the systems like CKAN or your local portals source code. When users like to test their output they can be pointed to SHACL validators such as: https://www.itb.ec.europa.eu/shacl/any/upload. It should be that the json-ld output of a system should be verifiable w.r.t. the SHACL associated with the spec. (Although I expect that one only find technical RDF errors.)

So back to the original request: using a reference to a published context versus to a expanded version. That is a matter of the objective of the example. Using a published context allows to condense the example and have the reader focus on the more important things, however it will loose the intuitive reading that the word "dataset" in the example is actually the uri `dcat:Dataset`. (On purpose I did a mapping on the class). In the case the reader must first open the referenced context in order to find the examples interpretation. Alternatively we are using a qNamed approach like the turtle representation, then the referenced context is probably equivalent with the prefix definitions. But the resulting json will be violating any naming convention practice in the json community.  

The current turtle examples are simple: there is no engineering or naming convention issue because they use the URIs. I propose we should not introduce these challenges into the DCAT specification. 
 
 

  




  

-- 
GitHub Notification of comment by bertvannuffelen
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1428#issuecomment-996273125 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 16 December 2021 23:28:11 UTC