- From: Mark Musen <musen@stanford.edu>
- Date: Tue, 24 Mar 2015 22:13:40 -0700
- To: Anthony Mallia <amallia@edmondsci.com>
- Cc: David Booth <david@dbooth.org>, "its@lists.hl7.org" <its@lists.hl7.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>, Peter Ansell <ansell.peter@gmail.com>, Matthew Horridge <matthew.horridge@stanford.edu>
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 <ansell.peter@gmail.com> 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 <amallia@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:david@dbooth.org] >> Sent: Tuesday, March 24, 2015 3:49 PM >> To: its@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 >> > >
Received on Wednesday, 25 March 2015 05:14:14 UTC