RE: Enhance json-ld to make remote collections first-class cititzens?

On 8 Mrz 2015 at 11:50, Dietrich Schulten wrote:
> Hi,
> 
> with the introduction of hydra:collection and hydra:manages we have
> introduced a second link facility to json-ld, in parallel to the plain
> json-ld link facility that uses a simple node object with @id property.
> 
> We had to do this, because the json-ld link facility is not suitable for
> remote collections.
> 
> It has a major drawback: clients have to check in two places to find out
> if a json-attribute has any values: the json-attribute itself and the
> hydra:collection property. That is not an optimal situation, but there
> is no other possibility for a vocabulary.
> 
> If we wanted to remove the second link facility from hydra, we would
> have to ask for an addendum to json-ld.
> 
> Just to give an idea, maybe we could ask for two new keywords @linked
> and (optional) @linkedItems:
> 
> {
>   "@context": {
>     "@vocab": "http://schema.org",
>     "hydra": "http://www.w3.org/ns/hydra/core#",
>     "acceptedOffer": {
>       "@container": "@linked",
>       "@linkedItems": "hydra:member" <-- optional
>     }
>   },
>   "@id": "http://example.com/store",
>   "acceptedOffer": {
>         "@id": "http://example.com/store/acceptedOffers"
>   },
>   "review": {
>         "@id": "http://example.com/store/reviews",
>   }
> }
> 
> where a json-ld processor must handle a json attribute with
> 
> "@container":"@linked"
> 
> definition in the @context so that it does not add the triple
> 
> </store> acceptedOffer </store/acceptedOffers>
> 
> to the RDF model of the current resource.

How would this be translated to RDF? How can it be represented in the underlying data model (detailed in the JSON-LD spec, I'm writing this offline).

 
> The spec addendum would also have to say what else the processor should
> do. E.g. it might describe that the json-ld processor may dereference
> the linked container and require it:
> - To add one triple to the current model for each item it finds in the
> target resource

Why should a JSON-LD processor do that? That seems like a bad separation of concerns/layering to me.


> - If there is a @linkedItems keyword, to look *inside* the received
> resource for the property defined by @linkedItems, and add one triple
> for each item found at @linkedItems. E.g. for each hydra:member of the
> received resource, add one triple to the current resource. That could be
> used by any vocab, not just by hydra, to point to a collection which is
> nested inside the target resource.

Well, every other vocab can use Hydra to achieve exactly the same. The advantage is that this way you are able to express this in RDF as well.


> The proposal above is just an idea. There might be other ways, e.g. the
> processor could construct an RDF representation of the remote collection
> which resembles our collection design, with reified statements etc. I
> just made up the keywords above to test the waters, I am not saying that
> should be our proposal to the json-ld group. My point is the following.
> 
> Since pretty much every json-ld author is also on this list:
> 
> - Do you generally agree that it would be desirable to use the same
> json-ld link facility for remote collections which is used for single items?

>From a JSON-LD point of view there's no difference. JSON-LD is not concerned about the vocabularies you use to express your data.


> - Based on the ideas given above or similar ideas, do you think it would
> be feasible?

Sure. But I don't think it would be the right thing to do.


> - If so, what are the chances to get such an addendum into json-ld?

Pretty low IMHO :-)


> Clearly that would be quite a change and takes a considerable amount of
> effort. Do you think it would be worth to go that route, too, while we
> also proceed with our new collection design?

To be honest and given my statements above unsurprisingly no. You are trying to work around a shortcoming of the underlying data model by introducing a quite complex and brittle processing model. I think the by far simplest way forward is to recommend vocabulary designers to not rely on rdfs:range but something more flexible such as schema:rangeIncludes. That way you can use a hydra:Collection without the hydra:collection/hydra:manages workaround.


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 13 March 2015 17:45:03 UTC