RE: Reconciling hydra rest semantics for collections with typical RDF entity relationships

Hi Gregg,

On Monday, February 03, 2014 11:24 PM, Gregg Kellogg wrote:
> 
> Excuse me for some random thoughts, but I've been reconciling using
> Hydra for an API which typically returns JSON-LD representations of
> entities described using schema.org. Similar issues may exist with the
> schema.org action vocabulary as well. As a simple example, I may want
> to express follows information for a Person. In Turtle, this might look
> like the following:
> 
> <http://example/people/gregg> a schema:Person;
>   schema:name "Gregg Kellogg"@en;
>   schema:follows <http://example/people/markus>,
> <http://example/people/kingsley> ...
> 
> However, given that the list of potentially people I follow could be
> large; using Hydra I may construct this using a separate relationship
> to a Collection:
> 
> <http://example/people/gregg> a schema:Person, :ApiPerson;
>   :follows <http://example/people/gregg/follows> .

This is a general problem of RDF. AFAICT, there's no way general way to
solve this issue for sets. If you would use a list, you could at least use
the list's head node (which generally is a blank node). Remember our
discussions in the JSON-LD group?

Both Schema.org with its ItemList and Hydra with its Collection take a
rather pragmatic approach. We could of course go ahead and define a
Collection's semantics so that

  x p c .
  c hydra:members y .

would entail

  x p y .

which is what you are looking for, right?



> :ApiPerson a hydra:Class;
>   hydra:supportedProperties [hydra:property schema:name],
> [hydra:property :follows] .
> 
> :follows a hydra:Link
>     rdfs:label "follows";
>     rdfs:comment "Collection of followed people";
>     rdfs:domain schema:Person;
>     rdfs:range schema:Person;

This range isn't correct unless you want
<http://example/people/gregg/follows> to be of type schema:Person.


>     hydra:supportedOperations [
>       hydra:method "GET";
>       hydra:returns hydra:Collection
>   ] .
> 
> If the referenced collection contained the following data:
> 
> <http://example/people/gregg/follows> a hydra:Collection;
>   hydra:members (<http://example/people/markus>
> <http://example/kingsley> .
> 
> After loading both the original document and the collection into a
> graph, I would now have the following:
> 
> <http://example/people/gregg> a schema:Person, :ApiPerson;
>   :follows <http://example/people/gregg/follows> .
> <http://example/people/gregg/follows> a hydra:Collection;
>   hydra:members (<http://example/people/markus>
> <http://example/kingsley> .
> 
> This now does not describe what I would want using the schema.org
> definitions. One way to reconstruct what I want would be to add more
> data to the collection document:
> 
> <http://example/people/gregg/follows> a hydra:Collection;
>   hydra:members (<http://example/people/markus>
> <http://example/kingsley> .
> <http://example/people/gregg> schema:follows
> <http://example/people/markus>, <http://example/people/kingsley> .
> 
> This is actually easier to do in JSON-LD:
> 
> {
>   "@context": {
>     "hydra": "http://www.w3.org/ns/hydra/core#",
>     "schema": "http://schema.org/",
>     "follower": {"@reverse": "schema:follows"}
>   }
>   "@id": "http://example/people/gregg/follows",
>   "@type": "hydra:Collection",
>   "members": [
>     { "@id": "http://example/people/markus", "follower":
> "http://example/people/gregg"},
>     { "@id": "http://example/people/kingsley", "follower":
> "http://example/people/gregg"}
>   ]
> }

That's the most straightforward solution I can think of.


> The issue is better for single-valued properties, as the property value
> would be the same as the entity identifier, which would result in what
> you would expect when merging both entity definitions.
> 
> I guess the question is, is this an expected usage pattern? Should the
> collection examples represent this, or should it be described as a
> recommended practice? Perhaps I've missed something.

I think this is definitely one of the most common usage patterns in Web
APIs. The question whether there needs to be a direct link between the
resources or whether you can go "through" a Collection is another question.
As long as the consumer of the data understands Collection/ItemList I think
it's not a problem. If it doesn't, it is of course.

Maybe Ruben has something more to say about this.. N3 *might* allow a nicer
solution but I think that's out of scope. Isn't it?



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 4 February 2014 18:26:40 UTC