- From: Ryan J. McDonough <ryan@damnhandy.com>
- Date: Sat, 28 Sep 2013 12:54:55 -0400
- To: "Markus Lanthaler" <markus.lanthaler@gmx.net>
- Cc: "'Linked JSON'" <public-linked-json@w3.org>, <public-hydra@w3.org>
Markus, Just following up on the HAL example. I've been taking a look at the HAL+JSON example here: http://stateless.co/hal_specification.html And I've been looking to see how this might be expressed in terms of JSON-LD. As I stated in my initial email, it seems that the "_embedded" property could be expressed as named graphs. Here's a sample I hacked up: { "@context": { "@vocab": "http://mashinator.io/2013/Linking#", "xsd": "http://www.w3.org/2001/XMLSchema#", "myapp" : "http://example.com/myapp#", "ea": { "@id": "http://example.com/docs/rels/" }, "total" : { "@id" : "myapp:total", "@type" : "xsd:integer" }, "currency" : { "@id" : "myapp:currency", "@type" : "xsd:string" }, "status" : { "@id" : "myapp:status", "@type" : "xsd:string" }, "currentlyProcessing" : { "@id" : "myapp:currentlyProcessing", "@type" : "xsd:integer" }, "shippedToday" : { "@id" : "myapp:shippedToday", "@type" : "xsd:integer" } }, "@graph": [ { "_default" : { "@id": "/orders", "links": { "next": { "@id": "/orders?page=2" }, "ea:find": { "template": "/orders{?id}" }, "ea:admin": [ { "@id": "/admins/2", "title": "Fred" }, { "@id": "/admins/5", "title": "Kate" } ] }, "currentlyProcessing": 14, "shippedToday": 20 } }, { "_embedded": { "@id": "/orders/123", "ea:order": [ { "_links": { "ea:basket": { "@id": "/baskets/98712" }, "ea:customer": { "@id": "/customers/7809" } }, "total": 30, "currency": "USD", "status": "shipped" }, { "_links": { "self": { "@id": "/orders/124" }, "ea:basket": { "@id": "/baskets/97213" }, "ea:customer": { "@id": "/customers/12369" } }, "total": 20, "currency": "USD", "status": "processing" } ] } } ] } I'm not so sure about the named graph labels, but I was merely trying to see how/if HAL could be expressed in JSON-LD. As you've already pointed out, HAL's "_embedded" resource offers much value since this is easily handled in JSON-LD already. It's a little more compact than the HAL version with the added benefit of being able to provide more detail about what the properties mean. But again, my motivations here are to see who to bridge the gap between something like HAL and JSON-LD as to illustrate how one would be able migrate to JSON-LD and/or Hydra. Ryan- On Sep 26, 2013, at 3:54 PM, Ryan J. McDonough <ryan@damnhandy.com> wrote: > Hey Markus, > > I'm trying to work out getting involved with Hydra right now. I'm trying to sort the details with my company and it's a bit of a slow process since it's something they haven't done before. So once that is cleared up, I'd be very interested in getting involved. > > I was at RESTFest last week and there were a lot of folks using HAL and Collection+JSON. Brian Sletten did the keynote talk and it was centered around semantic web technologies like RDF, SPARQL, etc.. People seemed interested, but somewhat reluctant to drop the work they've done in either HAL or Collection+JSON. Turns out too that GitHub is using JSON Schema internally for their API. But folks liked the idea of what Semantic Web tools could do for them, I think it felt like a major upheaval for them. > > So my motivations around this Linking context was to see if it's possible to model these existing formats using JSON-LD. My thinking is that it might make JSON-LD a bit more pallet able to those who think that JSON-LD is too complicated. The other thing is that, while link relations are not necessarily needed in JSON-LD, the concept is used quite bit within other formats and in link headers. With that said, it felt like bringing those concepts into JSON-LD could help address some of the perceived issue related to linking in JSON-LD. I'll cite one of Mark Nottingham's posts on the matter: > > http://www.mnot.net/blog/2011/11/25/linking_in_json > > With a content that can bridge the gap, a link relation type could be added and help make the transition a bit smoother. Again, I'm really only thinking out loud here ;) > > Ryan- > > On Sep 26, 2013, at 3:34 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: > >> Hi Ryan, >> >> I'm cc'ing the Hydra mailing, more on the why below :-) >> >> On Thursday, September 26, 2013 6:21 PM, Ryan J. McDonough wrote: >>> In looking at a number lot of JSON-based hypermedia formats such as HAL >> [1], >>> Collection+JSON [2], and JSON Schema [3], it seems there's a greater focus >>> on describing link relationships and not as much effort on describing >>> the data. There is a lot of activity and usage around these formats. >>> It also seemed that all of these formats could be expressed through >>> JSON-LD as well. >>> >>> I tried to take a stab some at a context that borrows some ideas from >>> all three formats for a URI Template validation service I'm working on. >>> I started with JSON Schema, but now looking at JSON-LD more and more. >> >> Looks as we are working on exactly the same thing :-) Have you already heard >> of Hydra [1]? I worked on it for quite some time now and recently started a >> W3C community group [2] to take it to the next step. >> >> >>> My first pass at a "Linking" context is here: >>> >>> http://mashinator.io/2013/Linking >>> >>> And here's a rough example: >>> >>> { >>> "@context": "http://mashinator.io/2013/Linking", >>> "@id": "http://uri-templates.herokuapp.com/uriTemplate", >>> "links": [ >>> { >>> "href": "http://uri- >>> templates.herokuapp.com/schema/uriTemplateStructure", >>> "rel": "describedBy", >>> "method": "GET", >>> "type": "application/schema+json" >>> }, >>> { >>> "template": "http://uri-templates.herokuapp.com/uri- >>> template{?template}", >>> "method": "GET", >>> "rel": "self", >>> "enctype": "application/www-form-urlencoded", >>> "type": "application/json" >>> } >>> ], >>> "error": { >>> "title": "An error happened", >>> "code": "1234", >>> "message": "it was kinda bad. " >>> } >>> } >> >> Being based on Linked Data, Hydra doesn't distinguish between "links" and >> other properties. It just happens that the value of some properties are IRIs >> where as values of other properties are literals. >> >> >>> It's wicked half baked at the moment and probably has other issues I >>> haven't thought of >>> yet. A few things came to mind while hacking this together: >>> >>> * In JSON-LD, the @id should be a dereferencable IRI. In that case, >>> would one need a property like "href" on a >>> Link, when you could just use @id? I think probably not, but I'm not >>> entirely sure. >> >> No, in JSON-LD the property is the href just as in the following example >> (context omitted) >> >> { >> "@id": "/page1", >> "nextPage": { "@id": "/page2" } >> } >> >> This connects /page1 via a nextPage relation to /page2. >> >> >>> * HAL uses the "_embedded" property and Collection+JSON uses terms like >>> "collection" and "items". Obviously >>> both of these values can be modeled in JSON-LD, but it seems more >>> efficient to use some type of @container >> >> You don't need HAL's _embedded at all in JSON-LD. Every entity is identified >> with @id. If there's just @id it's a reference. If there are other >> properties as well, it's "HAL-embedded". >> >> CJ's collection/items is a bit different so that you have to define those >> concepts to use them in JSON-LD. Hydra has Collections/members. >> >> >>> * When I look at HAL through RDF glasses, I see two named graphs: once >>> containing the data and the other >>> containing the control information. >> >> Interesting way to look at it. I've never seen it that way before. >> >> >>> I'm planning on taking these further as I think there's been a lot of >>> great ideas presented in all three of these formats, but I'd like to see >>> them all play nicely within JSON-LD. I'd appreciate any feedback on this >>> as I'm still new to JSON-LD, but have a good deal of time with RDF. >> >> I would love to collaborate on this. May I invite you to join the Hydra CG >> [2] and we take it from there? >> >> >> Cheers, >> Markus >> >> >> [1] http://www.markus-lanthaler.com/hydra/ >> [2] http://www.w3.org/community/hydra/ >> >> >> -- >> Markus Lanthaler >> @markuslanthaler >> >> >> >
Received on Saturday, 28 September 2013 16:55:24 UTC