- From: Niklas Lindstrom <lindstream@gmail.com>
- Date: Thu, 27 Mar 2014 11:24:56 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: エリクソン トーレ <t-eriksson@so.taisho.co.jp>, Markus Lanthaler <markus.lanthaler@gmx.net>, "public-hydra@w3.org" <public-hydra@w3.org>, "public-lod@w3.org" <public-lod@w3.org>, W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <CADjV5jeVR_XhCMY5E3cEpddLCRkDmH0V50W5U-oH1ikfQxvizw@mail.gmail.com>
Hi Gregg, Tore, On Thu, Mar 27, 2014 at 1:48 AM, Gregg Kellogg <gregg@greggkellogg.net>wrote: > On Mar 26, 2014, at 4:33 PM, エリクソン トーレ <t-eriksson@so.taisho.co.jp> wrote: > > > Alternative suggestion from the spectator seat: > > > >> Let's assume we want to build a Web API that exposes information about > persons > >> and their friends. Using schema.org, your data would look somewhat > like this: > >> > >> </markus> a schema:Person ; > >> schema:knows </alice> ; > >> ... > >> schema:knows </zorro> . > >> > >> All this information would be available in the document at /markus > (please > >> let's not talk about hash URLs etc. here, ok?). Depending on the number > of > >> friends, the document however may grow too large. > > > > </markus> a schema:Person ; > > rdfs:seeAlso </markus/friends/> . > > </markus/friends/> foaf:topic schema:knows . > > > > And in </markus/friends/> (or its redirection target): > > > > </markus> schema:knows </alice>, > > ... > > </zorro> . > > > > Replace foaf:topic with appropriate schema: properyy if necessary. > > That's an interesting idea; in a JSON-LD representation, it might look > like the following: > > { > "@id": "/markus", > "@type": "schema:Person", > "rdfs:seeAlso": { > "@id": "/markus/friends", > "foaf:primaryTopic": "schema:knows" > } > } > > { > "@id": "/markus/knows", > "@type": "hydra:Container", > "hydra:member": "/gregg" > } > This is basically the same pattern as the void:Linkset one, right? With the less precise predicate foaf:primaryTopic instead of void:linkPredicate. But that might be fine (especially since as mentioned VoID Linksets are about linking separate datasets). Btw, I suggest using schema:about instead, if we're using schema.org in general. > The only problem I see from a Linked Data perspective is that > </markus/friends> appears to be defined in the </markus> node definition, > so it wouldn't be obvious that you would do a further redirection to get > the container. > It is a separate resource, which should probably be described as such (using e.g. schema:CollectionPage). It is not a problem to describe such resources within other documents - in fact it is useful and often necessary (and as I said previously, a recommended practice when publishing linked data). For instance, the data received from </me> could contain: </me> a :Person . </me/details.en.html> a :WebPage; :about </me>; :name "About me"; inLanguage "en" . </me/details.sv.html> a :WebPage; :about </me>; :name "Om mig"; :inLanguage "sv" . That should be enough for a client to be able to decide what to fetch, depending on what the client understands and needs. Regarding lists of friends - what is the need for connecting artificial containers/lists of people, and just implying friendship? Is this really about managing reified triples? Why not just publish documents containing :knows links between me and my friends? The documents can of course be collections, paginated and so on. But that's a dataset partitioning mechanism (using linked documents), orthogonal from the links between me and my friends. Conflating this seems to cause the problems we're having here. (And no, I'm not much bothered by hash-or-slash and such (200 vs 303). What is troubling though is when the thing described is conflated with a description of it. That always causes problems. Just keep them separate and link them together (using e.g. schema:about, rdfs:seeAlso, iana:describedby), and we can partition descriptions using all the REST mechanisms we want.) Cheers, Niklas > > Gregg > > > Tore > > >
Received on Thursday, 27 March 2014 10:25:56 UTC