Using @index for hydra collection? - was: Re: Reading hydra:Collection as link relation

Hi,

Am 04.03.2015 um 22:54 schrieb Markus Lanthaler:
> On 27 Feb 2015 at 07:26, Dietrich Schulten wrote:

>> So a hydra:Collection can be seen as a two-faced link relation. When
>> used on the origin object it is an rfc-5988 link relation (walks and
>> quacks like a duck, see above).
> 
> Yes. You could look at it as a reified statement (http://www.w3.org/TR/rdf11-mt/#whatnot).

Yes, but I want to stress a different aspect of the collection design.
My point is that we have introduced a second link mechanism for remote
collections, alongside the simple link mechanism for remote *single*
items, which uses @id for the pattern

  context IRI -- link relation type --> target IRI

For collections we use:

  context IRI --
    link relation type "collection" --
      objects which contain the href of a remote collection and a rel

which can be read as

  context IRI --
    link relation type "links" --
      link relations where each link relation contains a href and a rel

Since we couldn't use the simple pattern for single items in json-ld,
there seemed to be no other way but introducing a second "link"
facility. The new link facility is the hydra:collection property, which
allows to add multiple rel-URI pairs, effectively.

> 
>> We have in fact answered a criticism Mark Nottingham brought up about
>> json-ld back in 2011, when he said that json-ld "also fails to provide a
>> mapping from 5988; where do I put the link relation type?".
> 
> I thought I did that already 4 years ago in the comments :-) In JSON-LD (and RDF in general) the link relation type is the property (or predicate if you like). Using RDF5988 terminology
> 
>    context IRI -- link relation type --> target IRI
> 
>    subject -- property/predicate --> object
> 
> 
>> Turns out he was right when a link to a remote collection is needed.
> 
> Yes, but it was always there...

As I see it, it wasn't there for remote collections. Rather, by
introducing the property hydra:collection we had to enable json-ld to
contain links to remote collections.

> 
> 
>> Seen that way I think I can make peace with our collection design :)
> 
> Good :-)
> 

;-)

That doesn't mean I find the collection design particularly elegant. But
as a vocabulary, we probably have no other means in hydra right now.

What makes it not elegant is the fact that we now have two linking
facilities, and clients must check both to find all related remote items
of the current context. To make it easier for clients to find their way
through our related collections, one could @index them by the property
each collection manages. It would be much easier to find the
:acceptedOffer and :review link if the value of :collection were an
indexed json object as shown below. If everybody agrees that @index
would be very helpful here, we could make it a SHOULD, so clients can
generally rely on the index.

{
  "@context": {
    "@vocab": "http://schema.org",
    "hydra:collection": {
      "@container": "@index"
    }
  },
  "@id": "http://example.com/store",
  "hydra:collection":
    {
      "http://schema.org/acceptedOffer": {
        "@id": "http://example.com/store/acceptedOffers",
        "hydra:manages": {
          "hydra:property": "acceptedOffer",
          "hydra:subject": "http://example.com/store"
        }
      },
     "http://schema.org/review": {
        "@id": "http://example.com/store/reviews",
        "hydra:manages": {
          "hydra:property": "review",
          "hydra:subject": "http://example.com/store"
        }
      }
    }
}

We might even say that a hydra client may expect as index:
- an absolute http URL,
- a curie (whose prefix is in the @context) or
- a non-URI or curie value that should be prefixed by the default vocab
prefix defined by @vocab.

I think that is as good as it gets with the current json-ld spec.

But I still hope that we can have the elegant way some day, see subject
"Enhance json-ld to allow remote collections" :)

Best regards,
Dietrich

Received on Sunday, 8 March 2015 09:52:00 UTC