- From: Alexander Dutton <alexander.dutton@oucs.ox.ac.uk>
- Date: Sun, 15 Dec 2013 11:45:58 +0000
- To: public-lod@w3.org
Morning, I'm playing with adding extra bits to a HAL document (http://stateless.co/hal_specification.html), so that I can get some RDF linked data out of it. Here's an example HAL document: > { > "label": "happy", > "_links": { > "self": {"href": "http://example.com/happy"}, > "narrower": {"href": "http://example.com/ecstatic"} > } > } I can then extend this to look like: > { > "@context": { > "skos": "http://www.w3.org/2004/02/skos/core#", > "label": "skos:prefLabel", > "narrower": "skos:narrower", > }, > "@id": "http://id.example.com/happy", > "@type": "skos:Concept", > "label": "happy", > "_links": { > "self": { > "@id": "http://id.example.com/happy", > "href": "http://example.com/happy" > }, > "narrower": { > "@id": "http://id.example.com/ecstatic", > "href": "http://example.com/ecstatic" > }, > } > } The point is that the document should still be meaningful to HAL clients, which can ignore the extra @context, @id and @type properties. However, I don't know how to get a JSON-LD parser past the "_links" key. As far as we're concerned it's meaningless and its children could/should be included one level up (but that result in the document no longer being HAL). I thought {"@container": "@index"} might be the answer, but that means that /the current key has meaning, and its children don't/, which is the wrong way round for my use case. Is there an answer? I realise I've missed the deadlines for commenting on the JSON-LD PR (http://www.w3.org/TR/json-ld/), so I hope it's me that's missed something as opposed to the functionality I want not being there. Best regards, Alex -- Alexander Dutton Linked Open Data Architect, Office of the CIO; data.ox.ac.uk, OxPoints IT Services, University of Oxford
Received on Sunday, 15 December 2013 11:46:26 UTC