RE: Schema.org properties having a collection as value and hydra:Collection

On 10 Okt 2014 at 12:15, Dietrich Schulten wrote:
> Am 10.10.2014 10:31, schrieb ☮ elf Pavlik ☮:
>> On 10/10/2014 09:52 AM, Dietrich Schulten wrote:
>>> Am 09.10.2014 09:33, schrieb ☮ elf Pavlik ☮:
>>>> On 10/09/2014 07:17 AM, Dietrich Schulten wrote:
>>>>> Properties like schema:review allow list or single values,
>>>>> but normally that is represented by an item of the target
>>>>> type or an array thereof. If I make the value of review a
>>>>> link, it seems perfectly okay if the link dereferences a
>>>>> Review or a Review[]. But can it point to a
>>>>> hydra:Collection?
>>>> have your read
>>>> https://github.com/HydraCG/Specifications/issues/41 ?
>>> 
>>> I did and from my understanding, the discussion seemed related to
>>> my question but there was no agreement about the solution yet. I

There is, and it is also noted in the issue. See

   https://github.com/HydraCG/Specifications/issues/41#issuecomment-48588100

   RESOLVED: Introduce four new properties, namely  hydra:collection ,
   hydra:manages ,  hydra:subject , and  hydra:object , to describe
   collections and associate them to entities. Declare it a best practice
   to inline the "manages block" in collection representations.

So, to answer your question. Schema.org doesn't use rdfs:range but the weaker schema.org/rangeIncludes. The difference is that rangeIncludes is merely a hint about what a client might find whereas rdfs:range defines the type of the value. If review would have a rdfs:range of Review, then following document

   {
      "@id": "/product",
      "review": {
        "@id": "/xyz",
        "@type": "hydra:Collection"
      }
   }

would actually be interpreted as

   {
      "@id": "/product",
      "review": {
        "@id": "/xyz",
        "@type": [ hydra:Collection", "Review" ]
      }
   }

because a client infers that all values of the "review" property are of type "Review". This is the reason we had ISSUE-41.
Schema.org, however, does *not* use rdfs:range and thus the first example above is completely fine.


[...]

> After looking at the use of fragment identifiers in the hydra vocab,
> it seems a url with fragment identifier points to an object having an
> @id with exactly that url with fragment identifier somewhere in a
> surrounding object identified by the url without fragment identifier.

Exactly. That's how it works.


> So the problem seems to be that the array of reviews has no
> identifier, for RDF the array is simply not there, rather it sees
> repeated triples of
> /products/1/reviews - member - review/1
> /products/1/reviews - member - review/2

Right. That's why we introduce as separate resource in between (the collection) so that we can reference it:

  /products/1 - review - /products/1/reviews

  /products/1/reviews - member - review/1
  /products/1/reviews - member - review/2

As long as the client "understands" what a Hydra Collection is, everything is fine. There also exists a "purer" approach that works with all vocabularies. I'm going to explain that in a separate email in a couple of minutes.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 13 October 2014 17:05:02 UTC