Hydra W3C Community Group Telecon Minutes for 2017-10-30

Thanks Pavlik for scribing. The minutes from this week's telecon are
now available at

   http://www.hydra-cg.com/minutes/2017-10-30/

The full text of the discussion is below, including a link to the audio
transcript.


-------------------------------------------------------------------
Hydra W3C Community Group Telecon Minutes for 2017-10-30

Agenda:
  https://www.w3.org/community/hydra/wiki/Conference_Calls#2017-10-30
Topics:
  1. Add use case creating events with PUT (PR-143)
  2. Heracles.ts PR-18 "Use cases/5.creating new event"
Action Items:
  1. Pavlik to create a PR to harmonize the usage of prefixes in 
    our use case documents
Chair:
  Markus Lanthaler
Scribe:
  elf Pavlik
Present:
  Markus Lanthaler, Tomasz Pluskiewicz, elf Pavlik, Karol 
  Szczepański
Audio:
  http://www.hydra-cg.org/minutes/2017-10-30/audio.mp3


Markus Lanthaler: Meeting: Hydra W3C Community Group Conference 
  Call
Markus Lanthaler: present+
elf Pavlik: present+
elf Pavlik is scribing.
elf Pavlik is scribing.

Topic: Add use case creating events with PUT (PR-143)

Markus Lanthaler: 
  https://github.com/HydraCG/Specifications/pull/143
Markus Lanthaler:  it already received reviews from Karol, Pavlik 
  and me
  ... Tomasz can you explain the current state of this PR?
Tomasz Pluskiewicz:  recent comment from Pavlik regarding 
  advertising a regular IRI which will handle adding new members
Markus Lanthaler:  you would need to communicate to client that 
  it has to re-fetch the collection to get IRI for adding another 
  resource
Markus Lanthaler:  i would include a nonce in the request, a 
  token that can get used once instead of messing with the IRI - 
  currently we have no way to do that in hydra
  ... other option would POST to the resource to get IRI which 
  later one can PUT to
Tomasz Pluskiewicz:  in previous comment you have 1-to-1 relation 
  with another resource, eg. private profile of a user
  ... it doesn't have the added complexity that you can't reuse 
  the same IRI
Markus Lanthaler:  do you think something blocks this PR?
Tomasz Pluskiewicz:  i see 2 more comments which need addressing
  ... 1 to use `If-Match` to tell difference between create and 
  replace
Markus Lanthaler:  so you want to avoid that if resource already 
  exists, that server will overwrite it when client attempts to 
  create new resoruce using the same IRI
elf Pavlik:  AFAIK conditional PUT works based on Etag
Markus Lanthaler:  i think you would need to do PUT with 
  `If_match: *`
Markus Lanthaler: PUT with If-Match: *
Markus Lanthaler: Server would reply with 412 Precondition Failed 
  if it already exists
Tomasz Pluskiewicz:  we still have issue that hydra doesn't 
  provide a way to require etags
Markus Lanthaler:  would be nice to have a way to instruct client 
  to do conditional request
Markus Lanthaler:  we could make it Use Case on its own and 
  remove it from this PR
Tomasz Pluskiewicz:  initially we said that this would extend UC5 
  but i decided to create a new file for it
Markus Lanthaler:  i don't have strong opinion about that, feel 
  free to do as it fits you
Tomasz Pluskiewicz:  we also have this other comment about HTTP 
  spec from you markus
Markus Lanthaler:  it basically says that PUT practically replays 
  that payload
Markus Lanthaler:  we should address this 'indirectly' 
  terminology
  ... instead have: "creating with know URL" or something like 
  that
  ... we also had an example that we had unclear relationship to 
  the collection
Markus Lanthaler:  you invented those new properties 
  http://example.com/vocab/createEvent i suggested that we may have 
  something like hydra:memberTemplate
Tomasz Pluskiewicz:  if we can stretch it to also work with 
  concrete IRIs
elf Pavlik:  i don't think we can define semantics of a property 
  that will hold either with template or with concrete resource
  ... i propose to for now go with hydra:memberTemplate and then 
  try to solve the non-template use case
Tomasz Pluskiewicz:  we also have this recursive traversal issue
Karol Szczepański:  i remember that we had some discussions on 
  mailing list about which definition takes precedence over others
  ... so i think more loose way of getting hypermedia was always 
  an option
  ... i believe that client should always be able to be more 
  'greedy' with lookups of hypermedias
Markus Lanthaler:  what did you have in mind when you called it 
  recursive
  ... did you mean following properties to other resources and 
  fetching those resources
Tomasz Pluskiewicz:  yes
  ... recursive means follow any link and look for operations in 
  those linked resources
  ... it could have cycles actually
Markus Lanthaler:  i don't see cycles a problem
  ... i think you can end up with some unintended operation with 
  such traversal
Tomasz Pluskiewicz:  if we go with `hydra:memberTemplate` we can 
  just follow that link and avoid recursive this way
Markus Lanthaler:  if we just follow that link and do NOT recurse 
  i see it fine
elf Pavlik:  I understand we settled on following 
  `hydra:memberTemplate` and NOT using recursive
Karol Szczepański:  one more question regarding this PR, I still 
  don't get it this very use case
  ... in PR i try to separate the creation from adding it
  ... in this UC we combine creation with adding member
Karol Szczepański:  how the client will know that create will add 
  to collection
  ... maybe we should add `schema:AddAction` together with 
  `schema:CreateAction`
Tomasz Pluskiewicz:  I think `hydra:memberTemplate` implies that 
  a resource will become member
Karol Szczepański:  I'd like to have only one way to define it
elf Pavlik:  in one of the issues i commented that we seem to 
  have 'create' on template but 'add' on collection
Markus Lanthaler:  for now we can just use `schema:AddAction` 
  only if we have operation directly on collection
  ... but not if we use template
Tomasz Pluskiewicz:  i think we still miss some pieces here
  ... for example like the adding existing members with PUT as in 
  vimeo case
Markus Lanthaler:  i would suggest focus on this one to make 
  progress
elf Pavlik:  let's don't see it as final design decision but as a 
  step in iterating on the issue

Topic: Heracles.ts PR-18 "Use cases/5.creating new event"

Markus Lanthaler: https://github.com/HydraCG/Heracles.ts/pull/18
Karol Szczepański:  I would wait with it and merge the other PR 
  for use case first
  ... since they address the same UC
Markus Lanthaler:  i would consider allowing Heracles users to 
  create some layer on top of it
Karol Szczepański:  we should at the same time not expect users 
  to do to much before the use client
Markus Lanthaler:  do you see anything as blocking or what you 
  see need for more input from the group
Karol Szczepański:  i see discussions ton tpluskiewicz's PR 
  helpful and sufficient
Markus Lanthaler:  let's iterate on github and reviewable and we 
  don't have to wait for next telecon
Tomasz Pluskiewicz:  we have some inconsistent way of using 
  prefixes in our snippets
Markus Lanthaler:  i would prefer not to use prefix for `hydra:` 
  and only for everything else
elf Pavlik:  should we remove existing prefixes for some 
  `schema:` terms ?
Markus Lanthaler:  it may help people to see what hydra provides 
  and what not
Karol Szczepański:  i would prefer to have no prefixes, 
  especially for common predicates
Markus Lanthaler:  also fine with that
elf Pavlik:  maybe someone can just do PR and propose changes?
Tomasz Pluskiewicz:  maybe let's make issue first and make PR 
  after agreeing on something
Markus Lanthaler:  or we can start PR with just one file
  ... to make it more concrete

ACTION: Pavlik to create a PR to harmonize the usage of prefixes in our use
case documents

Received on Monday, 30 October 2017 20:09:08 UTC