JSON-LD context inconsistencies - towards a single .jsonld file

[joepio]

We are working a project with an API that returns meetings with related motions and vote events from various Dutch municipalities. We want to add @context to our JSON responses, but currently, the popolo JSON-LD files are scoped for each individual class. For example, the parent attribute in an Organization refers to a schema:subOrganizationOf, while the parent of an Event is a schema:superEvent. If we were to combine these .jsonld files, one of the parent attributes would be incorrectly interpreted.

This could be prevented if popolo would have a single .jsonld file with a slightly adjusted mapping.

How do you feel about this? Is there a different way to deal with this problem, except for creating our own mapping by doing something different from popolo?

[jpmckinney]

JSON-LD is working on allowing @context to be scoped to @type which I believe will resolve the issue, so that you won't end up with conflicting mappings: json-ld/json-ld.org#415

[joepio]

That's a good suggestion, James. However, it is not supported by most parsers or serializers which limits the applicability. I still believe that having a single (generated) context file would be far easier to implement for developers.

I generated a single JSONLD context file using the popolo ontology and the owl2jsonld library.

It still needs some work, but would you accept a pull request for a single context file? It could be extremely useful for those who want to create a dynamic serializer for JSON-LD popolo data. Note, however, that while the used namespaces are the same as in popolo, the shortnames differ.

[jpmckinney]

@joepsz Sorry for the delay! I had a quick look at your context file. How did you resolve the property-name conflict issue? I couldn't find a mapping to subOrganizationOf. Did you omit properties that would conflict? But to answer your question, yes, I would consider merging a single context file.

[joepio]

@jpmckinney The previous JSONLD was incomplete since the subOrganizationOf property was still missing in the ontology. It's still a work in progress. We'll use the context internally and test it before I'll make a pull request.