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 <amal...@edmondsci.com> 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:da...@dbooth.org] > Sent: Tuesday, March 24, 2015 3:49 PM > To: i...@lists.hl7.org; 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 >
