- From: Markus Lanthaler via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Oct 2017 07:29:41 +0000
- To: public-hydra-logs@w3.org
Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 14 unresolved discussions.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 1 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcUoXZ9CSirPrVMr3o:-KxlEZShOyvX2pGRjej7:b-hc988v) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L1)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
Good point. Actually now that I think of it, it's really the opposite: event is created directly (rather then by posting it to the collection).
Or should I just call this "Creating with PUT" and not be fancy?
</blockquote></details>
Creating event with PUT is fine. Let's also update the file name before submitting this.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 7 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcV-ElopVA4z9XGxI0:-KxlEiP6xSmcVEpB2lTh:brxp9sq) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L7)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
I guess I wasn't sure myself and forgot about it. **The URL** sounds good?
</blockquote></details>
Sounds good.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 10 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcV7lBobudR-WyuFut:-KxlEv3QYkj1erwDcZMl:b-oycms2) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L10)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
Yes, part of. It's that and actually using doing PUT to the new resource itself. After all the server could link to concrete resource to PUT. Such as by minting a different URL for every GET. This is actually a good practice because let's the client take advantage of idempotency.
</blockquote></details>
PUT is not just create and it is not the only way to create a resource so we should spell out here why PUT might be preferable.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 34 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxZXSL5Owpv1cqTG5AR:-KxlFSTQ2Ewp1DqwF_39:bo9gs1f) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L34)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
That's a new feature I think. But including those operations in ApiDocumentation should already be possible with SupportedProperties
</blockquote></details>
Looks good. I'd only change getOperationOfType to getOperation**s**OfType as it always returns an array. You will also need to take the first result of the filter operation (currently operation is still an array).
I would probably also go a step further and also create a method to get rid of that filter statement to have something like
```
memberTemplate
.getOperationsOfType('http://schema.org/CreateAction')
.thatExpect('http://schema.org/Event')
.first();
```
@alien-mcl what do you think about this?
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 36 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxZY9gJ8iisuB-N2HfY:-KxlGbbdW9wHefUOlIED:b-9lt30u) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L36)):*
<details><summary><i>Previously, alien-mcl (Karol Szczepański) wrote…</i></summary><blockquote>
I agree - we shouldn't mutate the original operation.
</blockquote></details>
Great idea!
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 42 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcW88cm2en7sVc9HI0:-KxlGy3YZUZrNKYMu7xT:b-ja5dqh) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L42)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
As an example think of a discussion thread where the server offers random URIs for replies. This way the client can safely PUT multiple times without actually posting multiple comments.
So like @elf-pavlik says, if a resource doesn't exist yet is the client technically replacing or creating it? I think it's still creating. You can create resources but there is no representation.
I rephrased this sentence by the way.
</blockquote></details>
On second thought, I think we should split this off into a separate use case.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 64 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxYcL7VkgLlvZsRJlA4:-KxlHGFxArApOcnqbtGX:b-vs837j) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L64)):*
<details><summary><i>Previously, elf-pavlik (elf Pavlik) wrote…</i></summary><blockquote>
If we change method in that snippet from `PUT` to `POST`, how does the client know if it can use that resource just one and needs to refetch the collection to get new IRI before each time it wants to add to it (`PUT`) or it can continue using that resource (`POST`)
</blockquote></details>
Let's discuss PUT to a "placeholder URL" in the other comment or, likely better, in a separate use case.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 72 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxchCDgCDQQ4nzkMnf4:-KxlHbcmY0_R3PsHVN2j:b-64hq7f) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L72)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
@lanthaler this must have been discussed already. do you recall any GitHub issue touching mapping property?
</blockquote></details>
No. I also don't understand how a client would know how to replace the variable without property as it has no semantics then apart from being required.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 78 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxY28Opn5nMlgaMrFGV-r1-78:-KxlI3dRrxuXAU1PPE0h:b658214) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L78)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
> that just adds a resource that already exists
I think that's in scope of Use Case 9. Let's discuss there. Here I wanted to add an alternative to creating new resources (see UC 5).
In fact I'll just add in the considerations section a note that this method can be used to create resource outside of a collection context.
</blockquote></details>
I think it would be very surprising if it wouldn't be added to the collection as the IriTemplate is the memberTemplate of the collection.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 97 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxciNXcDOyiU5-EUn3l:-KxlIL4QPRJ-aNqvwflp:byqr3ct) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L97)):*
<details><summary><i>Previously, alien-mcl (Karol Szczepański) wrote…</i></summary><blockquote>
I'm not sure what is the problem - what does the JSON-LD spec says about relative URL's? How does it differ from the payload obtained with `GET`?
</blockquote></details>
The problem is that a POST/PUT don't have a base URL and so the relative URL can't be resolved. Using the target of the POST/PUT as base is not the right thing to do.
I filed https://github.com/HydraCG/Specifications/issues/144 to fix this later.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 115 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxY28Opn5nMlgaMrFGV-r1-115:-KxlJXmmPNY9juzio_D2:b-epl47y) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L115)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
FYI, actually it's `If-None-Match: *`, which prevents an update if any representation exists.
</blockquote></details>
Thanks for looking it up Tomasz.
---
*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 124 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcjZT6dVJharDWu_oJ:-KxlJq1TgMsgvn_lh-NK:bgjcx40) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L124)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
I'm just saying that there isn't enough information to go on until we come up with more meta data for operations. We also haven't defined any concrete semantics here AFAIK and thus the client cannot assume anything which is not explicitly stated in the above representation.
</blockquote></details>
Well, we can define the semantics however we want. IMO if the create operation is associated to a collection, it is reasonable to expect that new resource will become part of it. If the client doesn't want that, it should look for a create operation that isn't tight to a collection but, for instance, the class (Event in this case) instead.
---
*Comments from [Reviewable](https://reviewable.io:443/reviews/hydracg/specifications/143)*
<!-- Sent from Reviewable.io -->
--
GitHub Notification of comment by lanthaler
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/143#issuecomment-340682147 using your GitHub account
Received on Tuesday, 31 October 2017 07:29:43 UTC