FHIR Chat · Turtle Question · ontology

Stream: ontology

Topic: Turtle Question

Grahame Grieve (Jul 19 2017 at 20:33):

I've been working on getting my server to fully support turtle. I'm nearly there..... but some questions. @Harold Solbrig @David Booth @Eric Prud'hommeaux

Grahame Grieve (Jul 19 2017 at 20:33):

the examples in the spec have this:

Grahame Grieve (Jul 19 2017 at 20:33):

# - resource -------------------------------------------------------------------

<http://hl7.org/fhir/AuditEvent/example-pixQuery> a fhir:AuditEvent;

Grahame Grieve (Jul 19 2017 at 20:33):

then follows the rest of the resource as RDF. Then, there's this:

Grahame Grieve (Jul 19 2017 at 20:34):

# - ontology header ------------------------------------------------------------

<http://hl7.org/fhir/AuditEvent/example-pixQuery.ttl> a owl:Ontology;
  owl:imports fhir:fhir.ttl;
  owl:versionIRI <http://build.fhir.org/AuditEvent/example-pixQuery.ttl> .

# -------------------------------------------------------------------------------------

Grahame Grieve (Jul 19 2017 at 20:35):

this additional section is not documented, and I do not understand what it does, and why the identifying URL is different

Grahame Grieve (Jul 19 2017 at 20:37):

I also have a very specific question about the turtle: when should literals be wrapped as strings? and when should the xsd:type be specified?

e.g.

Grahame Grieve (Jul 19 2017 at 20:38):

     fhir:Coding.code [ fhir:value "24" ];
     fhir:index 1;

Grahame Grieve (Jul 19 2017 at 20:39):

the spec appears to say that the ^^xsd:type will always be present for fhir:value, but we do not conform to this now. Should we?

Grahame Grieve (Jul 19 2017 at 20:40):

one additional follow up question: there's no patch format for turtle is there? Does anyone think that there's a point to supporting patch on turtle?

David Booth (Jul 19 2017 at 21:10):

@Grahame Grieve the ontology header section is largely to make Protege happy. @Harold Solbrig can probably best answer the question about the URIs. You are right that it should be documented though. For documenting it, it would probably be enough just to add a little more to the embedded comment.

Harold Solbrig (Jul 19 2017 at 21:10):

this additional section is not documented, and I do not understand what it does, and why the identifying URL is different

First - what it does. The best way to do this is to work backwards:

If you import AuditEvent/example-pixQuery.ttl into a reasoner without simultaneously importing fhir.ttl, the reasoner assumes that all of the predicates in the RDF are annotation properties. If you first import fhir.ttl and then import example-pixQuery.ttl, same thing. Same for after as well. We've discussed this with various folks in the Protege and OWL communities and, according to them, this behavior is correct...

Thus, in order to do anything useful with an RDF record in the context of a reasoner, we (a) have to have fhir.ttl and (b) have to include it as a part of the RDF itself.

This leads to the next step. The RDF community never specified an import mechanism. The only widely adopted import mechanism that works is owl:imports. If you are going to use owl:imports, you have to have a named "document" to do the importing, and you do this by supplying a URI of type owl:Ontology.

Thus, the reason we have the header at all.

The reason that the name is different is that, not surprisingly, declaring that something is simultaneously a fhir:AuditEvent and a owl:Ontology confuses a reasoner badly and, in the Protege case, it remembers that example-pixQuery has a versionIRI and other ontology like properties, but forgets that it has other things

Harold Solbrig (Jul 19 2017 at 21:15):

the spec appears to say that the ^^xsd:type will always be present for fhir:value, but we do not conform to this now. Should we?

No -- the default type is xsd:string. We need to fix the spec. I'm just finishing a JSON to RDF converter that is driven entirely off of fhir.ttl and would be in a good position to give the documentation a once over...

While we're at it, however, we've got a couple of other issues. The first is that OWL doesn't know what to do with xsd:gYear, xsd:gYearMonth and xsd:date. At the moment, I've got a flag in the converter I'm using that says "OWL target", but, obviously, there are other things that need to happen as well.

Harold Solbrig (Jul 19 2017 at 21:19):

one additional follow up question: there's no patch format for turtle is there? Does anyone think that there's a point to supporting patch on turtle?

I think we need to involve @Eric Prud'hommeaux this one. There is an RDF path notation described in the Sparql spec, so patch notation would be possible, but I'd be interested in when/if anyone would use it and its ramifications

David Booth (Jul 19 2017 at 21:21):

@Grahame Grieve the short answer is that every literal should be wrapped in string "quotes" except for the fhir:index values, and they do not need explicit xsd:type annotations because Turtle supports some short-hand notation for strings and integers. So the example above is correct and conforming as written. It is equivalent to writing:

fhir:Coding.code [ fhir:value "24"^^xsd:string ];
fhir:index "1"^^xsd:integer;

Grahame Grieve (Jul 19 2017 at 23:09):

so it's not clear to me whether this ontology header should be part of the basic format for all FHIR resources - e.g. part of what my server does

Grahame Grieve (Jul 19 2017 at 23:10):

the alternative name is a real problem, because i don't have any alternative name. It's.. because of weakness on the HL7 server (static html pages on IIS) that the only way I can make access by media type work is by a redirect to an alternate name.

Grahame Grieve (Jul 19 2017 at 23:10):

but even then, I don't understand - there's no link in the RDF between the 2 names.

Grahame Grieve (Jul 19 2017 at 23:11):

and I think we need much better documentation about this than just a comment in some examples

Grahame Grieve (Jul 19 2017 at 23:13):

so I think that we should be explicit about fhir:value - whether it's in the turtle as a quoted string or not. And whether the xsd type is specified all the time, or just not if it's xsd:string.

Grahame Grieve (Jul 20 2017 at 03:14):

actually, there are 3 possibilities:
- always specify the type for fhir:value
- only specify the type for fhir:value when it is not xsd:string
- only specify the type for fhir:value when it is not fixed in fhir.ttl

Grahame Grieve (Jul 20 2017 at 03:16):

other than this issue and the ontology header one, next time i upgrade my server, it will fully support turtle

Harold Solbrig (Jul 20 2017 at 14:12):

so it's not clear to me whether this ontology header should be part of the basic format for all FHIR resources - e.g. part of what my server does

If the server doesn't supply the header, we won't be able to use the data directly in Protege or OWL -- we can point folks at the server, but will have to explain how to edit or front-end before using...

Eric Prud'hommeaux (Jul 20 2017 at 14:27):

- only specify the type for fhir:value when it is not fixed in fhir.ttl
assumes that folks have FHIR-specific parsers. A standard Turtle parser would emit the literal with an xsd:string datatype. This would be akin to publishing XML data and expecting folks to look for attribute values and CharData with two different xs:types.

Eric Prud'hommeaux (Jul 20 2017 at 14:29):

- only specify the type for fhir:value when it is not xsd:string
is nice because it makes the Turtle more pleasant to read but it's not semantically different from
- always specify the type for fhir:value

Eric Prud'hommeaux (Jul 20 2017 at 19:33):

one additional follow up question: there's no patch format for turtle is there? Does anyone think that there's a point to supporting patch on turtle?

There's a note for patch: https://www.w3.org/TR/ldpatch/#h-full-example

Grahame Grieve (Jul 20 2017 at 20:48):

that looks pretty underspecified to me. But if ever people want PATCH on turtle, that's the place we'll start

Grahame Grieve (Jul 20 2017 at 20:49):

and I think, based on Eric's comments, that we want '- only specify the type for fhir:value when it is not xsd:string'

Grahame Grieve (Jul 20 2017 at 20:50):

I'm not sure about the relationship between turtle literal and schema type. If we say the schema type is xsd:int, does that make this wrong?

[fhir:value "1"^^xsd:int]

Grahame Grieve (Jul 20 2017 at 20:51):

as for the ontology header... if I understood you right, @Harold Solbrig , the actual identifier used in the ontology is not particularly important - it just has to be different to the resource id, but since that's what you'd see in protege, it should be human-relatable?

Eric Prud'hommeaux (Jul 21 2017 at 12:47):

I'm not sure about the relationship between turtle literal and schema type. If we say the schema type is xsd:int, does that make this wrong? [fhir:value "1"^^xsd:int]

Per the RDF 1.1. Turtle spec, If there is no datatype IRI and no language tag, the datatype is xsd:string..

In XML, elements, attributes and text nodes are untyped until you apply XML Schema or XQuery to type it. In RDF, every parser is responsible for constructing datatyped literals. If you parse a document and then feed it and some OWL to some reasoner, it will use Datatype Entailment to either conclude "your xsd:int is also an xsd:integer" or whine if there's a conflict.

Basically, RDF literals are always typed even if the type isn't always conspicuous: sameTerm("ab", "ab"^^xsd:string) => true

Grahame Grieve (Jul 21 2017 at 14:11):

ok. but my question was about the "" thiemselves - is it wrong to have a string value labelled as an xsd:integer

Grahame Grieve (Jul 21 2017 at 14:11):

I conclude that it's not

Grahame Grieve (Jul 24 2017 at 16:01):

ok. test.fhir.org/r3 fully supports turtle now

Eric Prud'hommeaux (Jul 24 2017 at 21:26):

This is valid Turtle: <s> <p> "123"^^xsd:integer .

Eric Prud'hommeaux (Jul 24 2017 at 21:26):

/me hoping that was a useful answer

Grahame Grieve (Jul 25 2017 at 06:33):

yes thanks

Last updated: Apr 12 2022 at 19:14 UTC