- From: Chris Mungall <cjmungall@lbl.gov>
- Date: Wed, 05 Oct 2016 08:50:17 -0700
- To: "Alan Ruttenberg" <alanruttenberg@gmail.com>
- 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: <939BC7D9-C874-4043-B382-A00C17BCD57D@lbl.gov>
Just to be clear on what's in play here: 1. A TBD native JSON serialization whose structure directly follows functional/abstract syntax. Ideally this would be blessed by W3C 2. The [obographs](https://github.com/geneontology/obographs) JSON serialization that is semantically equivalent or a subset of OWL, and does not structurally mirror either RDF graphs or functional syntax, but instead has a structure geared towards certain kinds of applications (GO term enrichment, etc) I would be very supportive of 1 and hope that someone takes the lead here. For 2, this may have a more limited adoption in the broader semantic web world, it's more of a gateway drug, and there is no need for it to receive W3C blessing. I wouldn't consider 2 to be any competition for 1. We could also add to this list 3, a standard framing and context for a JSON-LD representation of OWL, but there doesn't seem to be a lot of demand for this. On 5 Oct 2016, at 8:15, Alan Ruttenberg wrote: > 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:50:53 UTC