On 03/24/2015 06:01 PM, Grahame Grieve wrote:
Well, there's 2 kinds of rdf representation. One is a statement of instance structure in rdf, and one is a statement of instance meaning. I'm not sure how to best describe the difference.
Do you mean the difference between the RDF serialization and the abstract RDF information content (a/k/a RDF model)? (The word "model" in "RDF model" may be a bit misleading because it is not being used in the same sense as "data model".) For example, Turtle, N-Triples and RDF/XML are all RDF serialization formats, and any of them can be used to serialize the exact same RDF information content.
Actually. I'm not sure whether there's only one of the latter either.
The point of the FHIR RDF effort is to *standardize* the RDF information content, so that for any given piece of FHIR instance data (in any standard FHIR format), two parties acting independently would get the exact same RDF information content by following the standard RDF mapping.
David Booth
And I'm not sure if a single rdf type is needed for the former, but I do think we need to distinguish them Grahame On Wednesday, March 25, 2015, Claude Nanjo <cnanjo.mailingl...@gmail.com <mailto:cnanjo.mailingl...@gmail.com>> wrote: Hi Grahame, Could it not be as simple as: GET [base]/[type]/[id], mime type : /some rdf mime type or non-rdf mime type/ where the rdf mime type could be application/rdf+json application/rdf+xml application/x-turtle ... with the supported mime types being specified in the conformance profile for that server? Why would we need 'Application/fhir+rdf'? Are you thinking of a new representation unique to FHIR? Claude. On Tue, Mar 24, 2015 at 1:21 PM, Grahame Grieve <grah...@healthintersections.com.au <javascript:_e(%7B%7D,'cvml','grah...@healthintersections.com.au');>> wrote: I don't think that we could decide that servers SHALL do RDF I had expected that we'd define an RDF format directly rather making it a transform from one of the existing formats - but, in fact, if we have a transform from one of the existing formats, it's just a question of who runs the transform? OTOH, I had naively expected that you would request RDF by it's mime type.... only, it's not so simple as that is it? I think that this is what we should do: GET [base]/[type]/[id], mime type : Application/fhir+rdf - the near form of RDF, a statement of structure of a resource. GET [base]/[type]/[id]/$rdf, mimetype = x - the far form, a statement of the known meaning of the content of the resource in some triple format Grahame On Wed, Mar 25, 2015 at 6:44 AM, David Booth <da...@dbooth.org <javascript:_e(%7B%7D,'cvml','da...@dbooth.org');>> wrote: 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 <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 <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 ******************************__******************************__*********************** Manage subscriptions - http://www.HL7.org/listservice View archives - http://lists.HL7.org/read/?__forum=its <http://lists.HL7.org/read/?forum=its> Unsubscribe - http://www.HL7.org/tools/__unsubscribe.cfm?email=grahame@__healthintersections.com.au&__list=its <http://www.HL7.org/tools/unsubscribe.cfm?email=grah...@healthintersections.com.au&list=its> Terms of use - http://www.HL7.org/myhl7/__managelistservs.cfm?ref=nav#__listrules <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules> -- ----- http://www.healthintersections.com.au / grah...@healthintersections.com.au <javascript:_e(%7B%7D,'cvml','grah...@healthintersections.com.au');> / +61 411 867 065 <tel:%2B61%20411%20867%20065> *********************************************************************************** Manage your subscriptions <http://www.HL7.org/listservice> | View the archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe <http://www.HL7.org/tools/unsubscribe.cfm?email=cnanjo.mailingl...@gmail.com&list=its> | Terms of use <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules> *********************************************************************************** Manage your subscriptions <http://www.HL7.org/listservice> | View the archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe <http://www.HL7.org/tools/unsubscribe.cfm?email=grah...@healthintersections.com.au&list=its> | Terms of use <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules> -- ----- http://www.healthintersections.com.au / grah...@healthintersections.com.au <mailto:grah...@healthintersections.com.au> / +61 411 867 065 *********************************************************************************** Manage your subscriptions <http://www.HL7.org/listservice> | View the archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe <http://www.HL7.org/tools/unsubscribe.cfm?email=da...@dbooth.org&list=its> | Terms of use <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
