W3C home > Mailing lists > Public > public-hydra@w3.org > November 2013

Re: hydra:expects and hydra:returns

From: Kuno Woudt <kuno@frob.nl>
Date: Thu, 07 Nov 2013 20:11:20 +0100
Message-ID: <527BE5D8.6060401@frob.nl>
To: public-hydra@w3.org
Hello Markus,

On 11/06/2013 07:13 PM, Markus Lanthaler wrote:
> Well, it depends on the point of view. A Web API client would like to know
> that the URLs changed. If it knows how to find the query the API to find
> information about a specific Musicbrainz identifier (using IRI templates
> e.g.) all is fine IMO.
>
> What practical problems do you see with this approach?

For clients who understand RDF, I don't see any problems -- as long as 
they get the same triples all should be fine.

I'm just worried that this will be confusing for developers who consume 
the response as JSON (without RDF).  When I rewrite my original example:

{
     "@context": "https://example.com/context.json",
     "@id": "https://example.com/musicvideos/murio.jsonld",
     "foaf:PrimaryTopic": {
         "@id": "mbrec:95dd147c-71ba-48b1-91f3-0bf2916e9ec4#_",
         "@type": "mo:Signal",
         "dbpedia:Director": {
             "foaf:name": "Ray Cuts",
             "sioct:microblog": {
                 "@id": "https://twitter.com/RayCuts"
             }
         }
     }
}

A developer who wants to consume this will look at this response and 
will have to deal with two identifiers.  One for the document and one 
for the topic.  The document-about-a-topic vs topic distinction is 
something I would rather not burden my (non-RDF) clients with.

If I didn't know about RDF and was designing this as a regular JSON API
the response would look something like this:

{
     "id": "95dd147c-71ba-48b1-91f3-0bf2916e9ec4",
     "director": {
         "name": "Ray Cuts",
         "microblog": "https://twitter.com/RayCuts"
     }
}

Which is easy to understand.  The promise of JSON-LD is that this can be 
turned into linked data with minimal changes to the structure of the 
response.  I would like to stay as close to this as possible, while at 
the same time making things machine-readable.


Anyway, for now I will implement things as you suggest.  This is 
conversation is probably more productive when I have a running system to 
talk about instead of a bunch of hypotheticals :)

-- Kuno / warp.
Received on Thursday, 7 November 2013 19:11:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:40 UTC