Re: OWL2 serialized as JSON?

Sorry, I can't just let the OWL-as-JSON thing go.

We've previously discussed the need for a JSON serialization independent 
of RDF, and most of us who work with OWL agree this would be a useful 
thing. I'm not sure there is any general uptake of this - I think there 
has been a whittling down effect where anyone doing anything heavy duty 
with OWL by now uses Java or a JVM language.

I still think the idea of a standard context for serializing OWL as 
JSON-LD (below) is a good one, for a subset of users, but it exposes too 
much of the RDF mapping of OWL.

In the bioinformatics community there is a need for something that is at 
the same level of abstraction as OBO-format, but less broken, with 
better OWL support, and serialized in JSON and/or YAML.

Here is what we have so far:
https://github.com/geneontology/obographs

And a post describing the motivation here:
https://douroucouli.wordpress.com/2016/10/04/a-developer-friendly-json-exchange-format-for-ontologies/

On 6 Aug 2013, at 15:45, Chris Mungall wrote:

> Remember this thread?
>
> It stirred a bit of discussion regarding the relative merits of a 
> direct
> serialization of OWL2 into JSON vs indirect via RDF. Probably somewhat
> academic, as here we are some time later and there don't seem to be 
> many
> people publicly shunting around OWL as JSON. I have a translation I 
> have
> been using for internal purposes but would like to abandon it in favor 
> of
> something more standard.
>
> I have shifted somewhat in the direction of an RDF-oriented solution. 
> IMany
> of the OWL class axioms I work with tend to generate fairly verbose 
> RDF
> (and consequently JSON derived from this). However, it's likely that 
> *any*
> translation to JSON will likely be ugly for my axioms.
>
> It seems JSON-LD has been gaining traction, and has nice features for 
> avoid
> verbosity. Is there any move to have a standard @context (perhaps 
> served
> from a standard URL) for OWL 2? Rather than having an abstract 
> discussion
> about relative merits it might help to see some concrete examples of
> ontologies of varying levels of complexity translated to JSON and 
> compacted
> as JSON-LD. I'm particularly interested in any JSON-LD tricks could be 
> used
> for a more compact encoding of axiom annotations.
>
> On Thu, Dec 1, 2011 at 10:17 AM, Chris Mungall <cjmungall@lbl.gov> 
> wrote:
>
>>
>> On Apr 7, 2011, at 5:54 AM, Bijan Parsia wrote:
>>
>>> On 7 Apr 2011, at 08:33, Jerven Bolleman wrote:
>>>
>>>> Hi Chris, All,
>>>>
>>>> I have the feeling that you are going about this the wrong way 
>>>> round.
>>>> I would first write a compelling JS api to deal with OWL concepts. 
>>>> And
>> later if necessary design an optimized serialization format.
>>>
>>> Actually this is pretty close to what I proposed to do.
>>>
>>> The structure spec defines a quite nice API for OWL ontologies:
>>>       http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/
>>> (The Manchester OWL API adheres to this.)
>>>
>>> The XML Serialization mirrors this closely:
>>>       http://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/
>>>
>>> All other serializations (Manchester Syntax, RDF syntax) have a 
>>> mapping
>> to the abstract model.
>>>
>>> Although there are some issues with things for serialization (e.g.,
>> prefixes). I'll try to separate these out (as I'm currently doing for 
>> XML).
>>>
>>> Thus, the idea is to produce something close to this (with perhaps a 
>>> few
>> tweaks) so that, e.g., the structural spec serves as documentation 
>> for the
>> API.
>>>
>>> I would generally recommend this as the preferred way to handle
>> additional mappings and concrete formats. That was certainly the 
>> intent of
>> the design.
>>
>> Hi Bijan. How is this progressing?
>>
>> I've written some code on top of the OWL API that generates json from
>> either expressions or axioms. The resulting json is fairly generic 
>> and
>> loosely corresponds to OWL-XML. Anything that is not a URI or a 
>> literal is
>> translated to a hash with a "type" key that maps to the axiom or 
>> expression
>> type, and an "args" arr. This is mostly for internal purposes write 
>> now -
>> I'd like to adopt whatever de facto standard there is out there.
>>
>>
>>> Cheers,
>>> Bijan.
>>>
>>
>>