Hi Everyone, We indeed will be moving Protégé 5 to the new OWL API in the next few weeks, which will allow us to serialize in JSON-LD for free. I’ve copied Matthew Horridge on this message, who is the best person to bug about this upgrade ;-)
Regards, Mark > On Mar 24, 2015, at 2:13 PM, Peter Ansell <[email protected]> wrote: > > Hi Tony, > > There has been gradual work on this area for a while. OWLAPI-4 has > support for JSONLD, via the Rio APIs at this point [1]. Once that > OWLAPI version flows through to Protege (in Protege-5 hopefully) [2], > it should also support JSONLD. > > Cheers, > > Peter > > [1] > https://github.com/owlcs/owlapi/blob/version4/rio/src/main/java/org/semanticweb/owlapi/rio/RioJsonLDParserFactory.java#L46 > [2] https://github.com/protegeproject/protege-owlapi/pull/3 > > On 25 March 2015 at 07:53, Anthony Mallia <[email protected]> wrote: >> David, >> >> Obviously this is an important discussion. >> Requirement 14 says the RDF instance (not FHIR XML or FHIR JSON) must be >> capable of being opened without further modification. When the instance is >> opened it is expected to form closure with the "Model" or Ontology of FHIR >> which is exchanged previously. >> Thus the RDF wire formats for passing both the Resource Instance and the >> FHIR Model must support the loading into a tool which must be able to infer >> or calculate the type assignments between the instances and the model >> classes. >> >> We need to get to the short list of recommended RDF serializations which >> need to be supported. >> >> Protégé currently supports: >> >> RDF/XML >> OWL/XML >> OWL Functional Syntax >> Manchester OWL Syntax >> OBO >> KRSS2 >> Latex >> Turtle (no Turtle viewer in Protégé desktop) >> >> JSON-LD is not an option right now. >> >> Folks will have their favorites - I work mainly in Manchester Syntax since >> it is the native language for expressions in Protégé. >> RDF/XML is probably the widest supported format. OWL Functional Syntax has >> some logical grouping readability advantages. >> Others are keen on Turtle. >> In most cases it does not matter because the underlying RDF/RDFS/OWL gets >> constructed regardless. However if we change the sample format every time it >> is very confusing and requires some learn time to figure out. >> It would be good to narrow the list. >> >> Tony Mallia >> >> >> >> -----Original Message----- >> From: David Booth [mailto:[email protected]] >> Sent: Tuesday, March 24, 2015 3:49 PM >> To: [email protected]; w3c semweb HCLS >> Subject: RDF information content and FHIR RDF requirement #14 >> >> On today's teleconference some discussion arose around the intent behind >> requirement 14 as it pertains to our FHIR RDF work: >> http://wiki.hl7.org/index.php?title=FHIR_Ontology_Requirements#14._RDF_Quality >> [[ >> 14. RDF Quality >> (MUST) Transformations into RDF must meet software quality checks including >> ontological closure. The RDF instance which is transformed from FHIR XML or >> FHIR JSON must be capable of being opened without further modification by >> widely available tools including Protégé and the RDF must meet quality >> checks including successful closure of graphs - all the links are understood >> by the tool. >> ]] >> >> Apparently different people on the call interpreted this requirement >> differently. Some interpreted it as applying to FHIR serializations that >> are transmitted on the wire; others interpreted it as applying to the >> underlying RDF that the transmitted data represents, independent of >> serialization. The difference shows up when we consider different >> strategies for mapping FHIR instance data to RDF. >> >> If we use a custom RDF mapping (Option 1 at >> http://wiki.hl7.org/index.php?title=FHIR_RDF_Mapping_-_Potential_Strategies >> ) >> then the FHIR group might adopt an RDF serialization as a third format (in >> addition to XML and JSON). This means that FHIR servers may send RDF >> serializations on the wire, and that RDF may be opened directly by standard >> RDF tools. >> >> OTOH, if we use JSON-LD (such as Option 2 at the above URL) then FHIR >> servers would be sending either XML or JSON-LD. Those who receive FHIR >> instance data in JSON-LD and want to interpret it as RDF might need to >> convert that JSON-LD to a different RDF serialization to open it in their >> favorite RDF tools if their favorite RDF tools do not already understand >> JSON-LD. (JSON-LD is the newest of W3C standard RDF >> serializations, and is not yet understood by all RDF tools.) The >> concern -- if I've understood correctly -- is that this would force the >> *recipients* to do this translation, instead of having the server sending a >> format that could be opened by all RDF tools directly. >> >> My own view is that, although I think there would be some benefit to >> encouraging the use of RDF serializations on the wire, I doubt that the FHIR >> group would agree to *requiring* FHIR servers to support an RDF >> serialization. It might be nice if they would, but I don't think it is >> important to our efforts. The goal of this sub-group is to facilitate the >> use of RDF as a common semantic model for interpreting instance data that >> may originate in any format, data model or vocabulary. The purpose is to >> enable data to be computable and semantically interoperable. >> Therefore what's important is just that we define a standard RDF >> *interpretation* for FHIR instance data, regardless of the serialization >> that is used on the wire. This standard RDF *interpretation* of FHIR >> instance data must meet requirement #14, but a transformation may still be >> needed in order to compute this RDF interpretation from a piece of FHIR XML, >> JSON or other instance data. >> >> What do others think? >> >> BTW, one of the key strengths of RDF is that it is independent of data >> formats or serializations. *Any* data can be viewed as an RDF serialization >> provided that a mapping has been defined from that data format into RDF. >> That mapping can even be defined after the fact: the original data format >> does not even need to have been designed with RDF in mind. This is one of >> the key features that enables RDF to act as a universal information >> representation. >> >> David Booth >> > >
