Re: Web Linking in JSON-LD

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
> 
> 
>