managing @id and/or @base for newly created resources / named graphs

[elf-pavlik]

Versions of UC5 and UC5.1 in #154 both create a new resource, using HTTP POST and HTTP PUT accordingly.

Current version of UC3 shows how to retrieve a collection with events representations embedded. In this use case, all the events have @id but based UC5 and UC5.1 one can't really tell how do those @id appear in the representation.

In UC5.1 client controls the IRI of newly created resource (using HTTP PUT) and could easily include @id in the payload. In UC5, the server controls the IRI of newly created resource (it can respect HTTP Slug: header but client can't assume it will), so client can't include @id in the payload. Payload in UC5, which client POST to the server currently uses a Blank Node with no @id.

In a case where payload includes only single blank node, possibly server could replace it with a Named Node based on IRI it assigns to the resource. IMO we should also anticipate payloads which will use @graph with multiple named nodes and blank nodes. In that case server could set @base or name the graph itself (given payload includes only one default graph).

While we don't have to address various possible scenarios right away. I think we should at least make all the use cases presenting consistent and reproducible scenario. Which means UC5 and UC5.1 should clearly explain how does each event get its @id.

[tpluscode]

I don't think I understand the issue :)

In a case where payload includes only single blank node, possibly server could replace it with a Named Node based on IRI it assigns to the resource

What you send to the endpoint using POST is not verbatim what the resulting resource representation will be. Here's how Fielding puts it

REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components

In the case of PUT, I think the @id is irrelevant either way. I only makes sense to match the requested resource.

With POST the server is free to reassign the @id any way it pleases. As much as it is free to ignore any other unrecognised or "wrong" property the body includes.

[tpluscode]

About the @graph you mean to have the client for example POSTs multiple new resources to a collection?

POST /collection HTTP/1.1 

[
  {
    "@id": "/collection/new-member-1",
    "name": "New member 1"
  },
  {
    "@id": "/collection/new-member-1",
    "name": "New member 2"
  }
]

How does the @base fit here? How is it important?

[elf-pavlik]

In UC5 client send this payload (a single blank node)

{
    "@context": "https://example.org/api/context.jsonld",
    "@type": "schema:Event",
    "eventName": "My brand new event",
    "eventDescription": "Hope it will work",
    "startDate": "2017-04-19",
    "endDate": "2017-04-19"
}

It could as well use single (default) graph

{
    "@context": "https://example.org/api/context.jsonld",
    "@graph": [
      {
        "@type": "schema:Event",
        "eventName": "My brand new event",
        "eventDescription": "Hope it will work",
        "startDate": "2017-04-19",
        "endDate": "2017-04-19"
      }
    ]
}

or something like this (which seems to cheat by not providing @base in the request)

{
    "@context": "https://example.org/api/context.jsonld",
    "@graph": [
      {
        "@id": "",
        "@type": "foaf:Document",
        "foaf:primaryTopic": "#this"
      }
      {
        "@id": "#this",
        "@type": "schema:Event",
        "eventName": "My brand new event",
        "eventDescription": "Hope it will work",
        "startDate": "2017-04-19",
        "endDate": "2017-04-19"
      }
    ]
}

@RubenVerborgh maybe you have better idea how Solid uses such relative IRIs in POST payload without providing explicit @base ? It seems to me that Solid client expect server to use IRI it will assign to the resource as the value for @base.

@tpluscode while I think we should eventually ensure that Hydra supports scenarios like in last two snippets. I think we should start with clarifying in UC5 how after posting a blank node, following responses to that resource (or collection embedding it) have representation with a named node (@id with IRI denoting the resource)

[alien-mcl]

I know that would be a workaround, but server could pick a resource that matches the operation's expectation. It won't work when multiple resources matching are available though. Still, I agree with @tpluscode on how @base fits here.