RE: "Plain JSON" vs Hydra

>> Now I know that it's completely valid to just add a link to a
>> context file in the response header not breaking backwards
>> compatibility, but then you don't get the full benefits of JSON-LD
>> in my opinion (like which actual @type a value is). Furthermore,
>
> The question is whether such information wouldn't also be very useful in a
> pragmatic JSON-only API!?

It is, but finding or defining the right links (for example on DBPedia) still takes additional time. Besides, I still experience a lot of people who are complaining about the payload. (I don't agree with them though!!!!)


>> For example, if I have
>>
>> {
>> "city": "London"
>> }
>>
>> Just converting it to
>>
>> {
>> "@context": {
>> "city": "http://schema.org/homeTown"
>> },
>> "city": "London"
>> }
>>
>> Doesn't give me the full benefits because I still can't fetch more
> information
>> about London.
>
> It is easily possible though:
>
> {
> "@context": {
> "city": { "@id": "http://schema.org/homeTown", "@type": "@vocab" },
> "London": "http://dbpedia.org/resource/London"
> },
> "city": "London"
> }

I apologize for not knowing that feature, I didn't know that was possible. But there are 2 things why I wouldn't prefer this approach: 1) a consumer would need to parse the @context to get the right links and 2) I love the use of static external context files as it makes development less complicated ;-)

A question I still have about this example is: why isn't it defined that London is a 'http://schema.org/City'? Perhaps I am doing it wrong because my only reference at the moment is Allegrograph's visualization tool Gruff which gives each 'type' an own colour so I can see which nodes area actually cities. I don't see the @type attribute being used often however, so does this mean it's completely useless without visualization?

Received on Wednesday, 6 August 2014 15:55:50 UTC