collections with manages block & Triple Pattern Fragments

[elf-pavlik]

Continuing from #137 (comment)

@elf-pavlik: do you have some insights to share on how you see Hydra and LDF working together to expose the same dataset?

@RubenVerborgh: I guess this is more of a question of doing the same things different ways in Hydra. The TPF interface uses Hydra to explain "you can filter by triple pattern". If there are multiple ways to express this, we need to discuss this, and perhaps eliminate.

If we look at snippet in UC#1EntryPoint

{
  "@context": "/api/context.jsonld",
  "@id": "/api",
  "@type": "hydra:EntryPoint",
  "collection": [
    {
      "@id": "/api/events",
      "title": "List of events",
      "@type": "hydra:Collection",
      "manages": {
        "property": "rdf:type",
        "object": "schema:Event"
      },
      "operation": {
        "@type": ["hydra:Operation", "schema:CreateAction"],
        "title": "Create new event",
        "method": "POST",
        "expects": "schema:Event"
      }
    }
  ]
}

This manages block works very similar to what I looked at doing with void:classPartition #126 (comment)
At the same time single manages block seems to work very closely to Triple Pattern Fragments. Actually with HTTP/2, Etag etc. I consider in projects I work on not to use collections which return members inline but rely on TPF and just fetch new members or members that have changed.
I think we should take some time to clarify how collections with manages block and TPF supposed to work together, maybe even write side by side comparison with guidelines about strengths and weaknesses of each one.

[elf-pavlik]

Following up on #148 (comment)

We may also need to clarify when we use Collection - view -> PartialCollectionView and where do we use sub-collection Collection - collection -> Collection.

The first (view) seems more like client driven data fragment/partition, while the second (collection) seems more like server driven data fragment/partition.

[elf-pavlik]

This commit replaces 'collection' centric approach, with triple centric approach. Client instead of looking for collection with manages block would just rely on TPF to get the same information. 33ab45a

[RubenVerborgh]

@rubensworks @joachimvh @mielvds @pietercolpaert Any thoughts on this?

[pietercolpaert]

A TPF could also have a manage block, right? You could have multiple TPF startfragments that manage different types?

I don’t quite understand the question here though: why would LDF be something different than a Hydra API?

[mielvds]

I don't really follow either. What is the exact difference? What are the semantics of manages?

[elf-pavlik]

Hi @pietercolpaert & @mielvds , please let me try to explain better. You can find information on how manages suposed to work on https://www.w3.org/community/hydra/wiki/Collection_Design

In my example snippet above taken from UC#1EntryPoint

 "manages": {
        "property": "rdf:type",
        "object": "schema:Event"
}

Simply means that members in that collection all follow ?member rdf:type schema:Event . pattern. In snippet from the wiki page explaining manages. I see it similarities to void:classPartition, I have example using it in #126 (comment)

    "manages": {
      "property": "schema:knows",
      "subject": "/alice"
    }

It simply means that all members follow </alice> schema:knows ?member pattern. I see it similar to LDP Direct Container

So far I don't see major difference from using TPF to get IRIs of resources matching given triple pattern. Collections can inline / JSON-LD embedd representations of those resources in the representation of the collection, still given HTTP/2 I don't see it an advantage for all application scenarios, for example based on capability to cache representation of each resource.

As a person developing web services (acting mostly as servers) and web applications (acting mostly as clients) using API based on Hydra. Currently I don't see clear guidance on when to use collections with manages or TPF or maybe my API should provide both at the same time.

Another difference relates to creating new resources, currently UC#5 provides example of creating new resources using HTTP POST while UC#5.1 using HTTP PUT and hydra:memberTemplate still pending approval in #158 , both of them also have variants in also pending #154 Both cases follow what I see as LDP style approach where client relies on collection advertising operation of creating new resources schema:CreateAction (which also gets added to that collection) and a way to perform that operation (once again #154 proposes separating semantic action on given resource from an operation, possibly on other resource which handles that action).

Without collections, relying on proposed in #158 hydra:memberTemplate doesn't seem to work any more. At the same time, a dataset which allows creating new resources, could advertise operations like schema:CreateAction directly on itself, especially if they use 'flat' URI namespace, eg. all resources follow simple /{uuid} which doesn't should work just fine when querying dataset with LDF/TPF. So here collections seem helpful if server wants to use 'deep' URI namespace like /events/{uuid} and /people/{uuid} while using HTTP PUT to create resources (which would require different URI templates).

I consider making PR which would enable TPF based approach for the current set of use cases. It wold co-exist with collection based approach and we could see where they play well together and where they seem to step on each other toes.

[alien-mcl]

As a person developing web services (acting mostly as servers) and web applications (acting mostly as
clients) using API based on Hydra. Currently I don't see clear guidance on when to use collections with
manages or TPF or maybe my API should provide both at the same time.

It depends on who do you want to enable to utilize your API. Hydra will be more generic, TPF is on top of Hydra and may introduce it's own mechanism that won't be visible for Hydra generic client. You may end up with conclusion that Hydra itself is not enough and you may be forced to use other means of expression - still, it depends on the target audience.
Let's hope there will be frameworks that won't enforce on you any specific architectural decisions and will allow you to expose your API with different tools.