Re: OWL2 serialized as JSON?

I was  thinking about that issue, coming to the conclusion that named
parameters were the most obvious choice, with the laziest available
parameter names being  the appropriate OWLAPI property names, using a
"type:"  value to indicate axiom / expression type.

There is also some win available by mixing in some Manchester-like frames
for some constructs, but this  is limited due to the lack of infix.

Simon

On Oct 4, 2016 1:17 PM, "Chris Mungall" <cjmungall@lbl.gov> wrote:

> Hi Michael,
>
> Yes I agree, this is what Bijan and I were circling around in the original
> discussion. There were questions as to how "S-expressiony" the mapping
> would be (like OWL-XML) vs having named parameters. I think the latter
> makes sense.
>
> The additional JSON format I am proposing would be structurally different
> but semantically equivalent or a well-defined subset, and it would be aimed
> at a different use case (e.g. bioinformatics programmers who was simple
> access to graph-representations of the existential graph of a T-Box)
>
> On Tue, Oct 4, 2016 at 12:13 AM, Michael Schneider <m_schnei@gmx.de>
> wrote:
>
>> Hi Chris,
>>
>> I don't know if anyone has been working on an OWL 2 JSON serialization
>> yet, but I would expect this to be relatively straightforward, if one would
>> create it along the lines of the OWL 2 Functional Syntax [1], in a similar
>> way as it has already been done for the OWL 2 XML Serialization [2].
>>
>> [1] <https://www.w3.org/2007/OWL/wiki/Syntax>
>> [2] <https://www.w3.org/2007/OWL/wiki/XML_Serialization>
>>
>> Michael
>>
>> Am 04.10.2016 um 07:12 schrieb Chris Mungall:
>>
>>> 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-fri
>>> endly-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
>>>     <mailto: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.
>>>         >
>>>
>>>
>>>
>>
>