RE: hydra:expects and hydra:returns

On Wednesday, November 06, 2013 7:33 AM, Kuno Woudt wrote:
> On 11/05/2013 03:29 PM, Markus Lanthaler wrote:
> > On Sunday, November 03, 2013 6:07 PM, Kuno Woudt wrote:
> >> {
> >>       "@context": "https://example.com/context.json"
> >>       "@id": "mbrec:95dd147c-71ba-48b1-91f3-0bf2916e9ec4#_",
> >>       "@type": "mo:Signal",
> >>       "foaf:isPrimaryTopicOf": [
> >>           { "@id": "mbrec:95dd147c-71ba-48b1-91f3-0bf2916e9ec4" },
> >>           { "@id": "https://example.com/musicvideos/murio.jsonld" }
> >>       ],
> >>       "dbpedia:Director": {
> >>           "foaf:name": "Ray Cuts",
> >>           "sioct:microblog": { "@id": "https://twitter.com/RayCuts"
> }
> >>       }
> >> }
> >
> > I wouldn't model things like this. In the context of Hydra we are
> > talking about Linked Data applications and thus
> > https://example.com/musicvideos/murio.jsonld should be the "primary"
> > resource in the representation above. You could then say that
murio.jsonld's
> > foaf:primaryTopic is mbrec:95dd... which is a mo:Signal
> 
> My concern with this is that it gives focus to the "wrong" identifier.
> The identifier for the document is only of interest when interacting
> with my service, the identifier for the real-world-thing my document is
> about is what is of interest to clients -- in particular clients who
> will consume this as json (not RDF or linked data).

Well, from an interaction point of view, the URL is nevertheless the most
important thing. You could of course declare that the two are owl:SameAs or
alternative just introduce something like mbrId which then isn't a URL but
the string 95dd14...

{
  "@id": "https://example.com/musicvideos/murio.jsonld",
  "mbrId": "95dd14...",
  ...
}


> My experience with MusicBrainz is that there are many databases out
> there using musicbrainz identifiers to talk about music and the artists
> making that music:
> 
> - audio fingerprints at http://acoustid/track/{mbid}/
> - coverart at http://coverartarchive.org/release/{mbid}/
> - reviews at http://www.bbc.co.uk/music/artist/{mbid}.xml
> - artist pictures at http://fanart.tv/artist/{mbid}/
> etc..

Right, you could of course also convey the semantics of such URL templates
to a client by using Hydra's IriTemplate:

{
  "@context": ...,
  "@type": "IriTemplate",
  "template": "http://example.com/whatever/{?mbid}",
  "mappings": [
    {
      "@type": "IriTemplateMapping",
      "variable": "mbid",
      "property": "mb:id",
      "required": true
    }
  ]
}

(this assumes that "mb:id" represents a Musicbrainz ID)


> Many of our customers have a local copy of the database for which they
> maintain a mapping with their internal databases and which they query
> locally.  There is value in all these services using a common
> identifier to represent a particular artist (or track, or album, etc..)
> so they can talk to eachother.

Never doubted that but as you say, it's a mapping.


> So, similarly, if someone has a local copy of my hypothetical music
> video database, all the document URLs will have changed because
> they're running the service on e.g. http://localhost:8080/.  But the
> identifier for a particular music video should stay the same --
> regardless of whether I am minting these myself or use musicbrainz
> identifiers.

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?


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 6 November 2013 18:14:08 UTC