On Mar 27, 2014, at 3:24 AM, Niklas Lindström <[email protected]> wrote:
> Hi Gregg, Tore, > > On Thu, Mar 27, 2014 at 1:48 AM, Gregg Kellogg <[email protected]> wrote: > On Mar 26, 2014, at 4:33 PM, エリクソン トーレ <[email protected]> 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. Yes, I think we need reasonably universal predicates here, and voad:linkPredicate may be the one. However, from a schema.org-centric view, there should be something appropriate for use using just schema.org. > 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. Sure, it's not a technical problem, but, while it may be fragile, in a WebApp if I see an IRI as an object, but not a subject, the logic is clearer to dereference it to get a subject. If it is already a subject (even if just having foaf:primaryTopic or void:linkPredicate) you might assume that you've already done such a retrieval. We can certainly provide some direction for an app to know when it has an entity, if that is basically a surrogate or it should be considered "completed". > 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. I think it would be logical to make the relationship explicit between the primary subject and each member of a list. This may have been eliminated in examples for brevity. Pat also suggested describing rules to determine that, but many applications aren't really rule based (at least those that want to run in linear time :), so doing these entailments on the server makes sense. > (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.) In real-world situations with organizations coming from a different perspective, theory often clashes with practicality. The "lesser of two evils" dictum would be to first make sure that something gets published, even if it is semantically fuzzy. But, that's a perma-thread for a different day :) Gregg > Cheers, > Niklas > > > Gregg > > > Tore > > >
