- From: Chris Mungall <cjmungall@lbl.gov>
- Date: Tue, 04 Oct 2016 11:22:18 -0700
- To: "Ignazio Palmisano" <ipalmisano.mailings@gmail.com>
- Cc: "Michael Schneider" <m_schnei@gmx.de>, public-owl-dev@w3.org
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-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 >>>> <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 Tuesday, 4 October 2016 18:22:51 UTC