- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Tue, 17 Mar 2015 16:38:04 -0700
- To: Grahame Grieve <grahame@healthintersections.com.au>
- Cc: David Booth <david@dbooth.org>, Linked JSON <public-linked-json@w3.org>, Jim McCusker <mccusj@rpi.edu>, Markus Lanthaler <markus.lanthaler@gmx.net>, Manu Sporny <msporny@digitalbazaar.com>
- Message-Id: <9E550699-3302-4DD8-ABF7-8B613D3EDB6A@greggkellogg.net>
> 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 <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 <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 <mailto:david@dbooth.org>> wrote: > This question came up here: > https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0065.html <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 <http://hl7.org/fhir/StructureDefinition/Substance>", > "resourceType": "Substance", > ... > } > > it would be nice if we could just write: > > { > "@context" : "http://hl7.org/fhir/StructureDefinition/Substance <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 <http://www.healthintersections.com.au/> / grahame@healthintersections.com.au <mailto:grahame@healthintersections.com.au> / +61 411 867 065
Received on Tuesday, 17 March 2015 23:38:36 UTC