Re: [FHIR JSON-LD] Possible to generate implied triples from @context?

thanks

Well David, it might be obvious to me, but obviously not. So, really, then,
for use, resourceType has to stay. So much for my idea. This means that we
just overlay @context over the top of what we have already, following a
similar pattern.

btw, "for example providing a sub-context that would take effect for values
of a particular term" - yeah, that's what we were talking about. It's
another thing that seems obvious to me: moving the burden of resolution
from the instance to the knowledge layer - which, after all, is about doing
things with knowledge ;-)

Grahame


On Wed, Mar 18, 2015 at 10:38 AM, Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> On Mar 17, 2015, at 3:11 PM, Grahame Grieve <
> grahame@healthintersections.com.au> wrote:
>
> but my point was, if you have  "@context" : "http://hl7.org/fhir/
> StructureDefinition/Substance", you don't need "resourceType": "Substance"
>
> Presumably the @context information makes it's way into the RDF somehow?
>
>
> Nothing in the @context directly causes any RDF to be generated, only when
> terms in the context are used within the JSON does it provide the “context”
> to know how to generate something. Typically, this is confined to turning
> terms and prefixed names into IRIs, or for knowing if the value of a
> property has a datatype, language or is an IRI.
>
> The important thing to remember about the context is that it does not
> provide any content itself, simply a _context_ for the JSON so that it can
> be properly interpreted. The complexity of handling a context typically
> comes from the need to round-trip JSON through expansion and compaction, or
> even through some other RDF format. Given that multiple terms can resolve
> to the same IRI but with different container or datatypes, this can be
> challenging. Adding more information to a term definition which has content
> associated with it would make it more challenging still.
>
> There have been previous discussions about doing more in the context, for
> example providing a sub-context that would take effect for values of a
> particular term. There also seems to be some thought that a term definition
> might provide some data which could be emitted, such as an rdf:type triple;
> this seems less likely for a future group to take up.
>
> At some point, the different feature requests that would go into a JSON-LD
> 1.1 or 2.0 would need to be vetted and used to create a charter for a new
> group. Of course, members with adequate free time to do this also need to
> be found, and most of the original authors/editors are pretty committed
> right now typically putting JSON-LD to use for other specifications. But,
> given popular support, a WG with a charter to advance JSON-LD to address
> shortcomings and/or features of the current spec seems like it is
> inevitable.
>
> A number of features to be considered for the next JSON-LD version are
> tracked on github [1]. Consider creating a new feature request if it isn’t
> covered.
>
> Gregg
>
> [1] https://github.com/json-ld/json-ld.org/milestones/JSON-LD.next
>
> Grahame
>
>
> On Wed, Mar 18, 2015 at 9:08 AM, David Booth <david@dbooth.org> wrote:
>
>> This question came up here:
>> https://lists.w3.org/Archives/Public/public-semweb-lifesci/
>> 2015Mar/0065.html
>>
>> Is it possible to generate an RDF triple without an explicit property in
>> the JSON-LD?  Instead of having to write:
>>
>> {
>>   "@context" : "http://hl7.org/fhir/StructureDefinition/Substance",
>>   "resourceType": "Substance",
>>   ...
>> }
>>
>> it would be nice if we could just write:
>>
>> {
>>   "@context" : "http://hl7.org/fhir/StructureDefinition/Substance",
>>   ...
>> }
>>
>> but still generate an RDF triple like:
>>
>>   _:foo fhir:resourceType fhir:Substance .
>>
>> Is this possible?
>>
>> Thanks,
>> David Booth
>>
>>
>
>
> --
> -----
> http://www.healthintersections.com.au / grahame@healthintersections.com.au
> / +61 411 867 065
>
>
>


-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065