- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Wed, 5 Oct 2016 11:15:20 -0400
- To: Chris Mungall <cjmungall@lbl.gov>
- Cc: Ignazio Palmisano <ipalmisano.mailings@gmail.com>, Michael Schneider <m_schnei@gmx.de>, "public-owl-dev@w3.org" <public-owl-dev@w3.org>
- Message-ID: <CAFKQJ8nW7dgU5cabeuiR-WkBtCLduwLBbuv1zQadU1qLxLrOxA@mail.gmail.com>
We already have a normative syntax for exchange - RDF/XML. If one needs unconditional interoperation then that's the syntax to generate. In my view other syntaxes are useful in other contexts and can be encouraged. I also support the idea of a native owl syntax for JSON, designed to be easy to parse and do syntactic manipulations with. To minimize the effect on interoperability I suggest that standard includes a JavaScript implementation translating the OWL syntax to and from RDF/XML minimally, and probably to and from whichever JSON/RDF standard wins. Interoperability degradation would be minimal since it any JavaScript developer could easily interoperate with the existing tool chain without having to ask for vendor support or jumping through hoops to find a library. Whatever is chosen for JSON/RDF becomes another de facto format for OWL, so no more work is needed (or desired,IMO) in that direction. Alan On Tuesday, October 4, 2016, Chris Mungall <cjmungall@lbl.gov> wrote: > > > On 4 Oct 2016, at 10:25, Ignazio Palmisano wrote: > > On 4 Oct 2016 18:17, "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) >> >>> >>> >> Having read your explanation post but before seeing the proof of concept >> implementation: this could be wrapped easily as a pluggable format for owl >> api for easy experiments (we intended to have a way to add/remove parsers >> and storers without the need to rebuild the owl api, but this has had only >> limited testing with real implementations). >> > > This would be useful > > This does little for your needs except removing one obstacle to adoption: >> if all works out as it's supposed to, you don't have to wait for Protégé >> or >> owl api to catch up with your work for people to start using it - it would >> work on the current protégé build. >> > > Well, there are other advantages in having it be better integrated with > the owlapi > > I'm not sure there is such a use case for saving from within Protege. The > use of obographs is less during the ontology development cycle and more > part of the publish-release cycle. But nevertheless it might be nice to > have. > > Cheers, >> I. >> >> 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. >>>>> > >>>>> >>>>> >>>>> >>>> >>> > > >
Received on Wednesday, 5 October 2016 15:16:01 UTC