- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 21 Aug 2017 21:42:02 +0200
- To: "'Hydra'" <public-hydra@w3.org>
The minutes from this week's telecon are now available at http://www.hydra-cg.com/minutes/2017-08-21/ The full text of the discussion is below, including a link to the audio transcript. ------------------------------------------------------------------- Hydra W3C Community Group Telecon Minutes for 2017-08-21 Agenda: https://www.w3.org/community/hydra/wiki/Conference_Calls Topics: 1. Heracles.ts PR#11: Implementation necessary to achieve use case 3 - obtaining events 2. Use cases PR#132: use manages block to advertise type of collection members Resolutions: 1. Merge PR #132 that uses the manages block to advertise type of collection members Action Items: 1. Pavlik to add some more use cases that illustrate the manages feature introduced in PR #132 2. Pavlik to create a use case for issue #134 (adding existing resources to collections) Chair: Markus Lanthaler Scribe: Markus Lanthaler Present: Markus Lanthaler, Karol Szczepański, elf Pavlik Audio: http://www.hydra-cg.org/minutes/2017-08-21/audio.mp3 Markus Lanthaler is scribing. Topic: Heracles.ts PR#11: Implementation necessary to achieve use case 3 - obtaining events https://github.com/HydraCG/Heracles.ts/pull/11 Markus Lanthaler: interface more low-level than i expected [scribe assist by elf Pavlik] Karol Szczepański: indeed, interface is low-level ... was thinking about creating something on top of it ... but would like to get some more feedback as this will affect the further work ... I'll try to implement something more sophisticated in the coming days ... but I'd really love to get some more feedback as this is the interface we will stick with ... so it's a crucial decision Markus Lanthaler: completely agree elf Pavlik: I think we should keep the client implementation as close as possible to the pseudo-code in the use cases ... that pseudo-code was written before we started working on the client ... we can then replace the pseudo-code with real code Markus Lanthaler: good point Markus Lanthaler: karol, would you like to merge this one first or should we iterate on this one till we are happy Karol Szczepański: let's keep it open and iterate till we are happy Markus Lanthaler: ok, I don't think we need a formal resolution for this. let's just continue working on it ... anything else we should discuss about this? Karol Szczepański: not at this point, I'd just like to stress that we should get more feedback on the API elf Pavlik: at some point I think Karol made a comment somewhere saying that he wouldn't like many abstractions on top of the JSON provided by the server ... could you please clarify this Karol? Karol Szczepański: we agreed to not touch the original response ... I only added a "hypermedia" field to it elf Pavlik: does this also apply to the EntryPoint? ... It would be a good candidate to add more abstractions to make it easier to work with the data Karol Szczepański: for the EntryPoint my approach is the same ... I just add a hypermedia field which collects links, operations etc. in a single place Markus Lanthaler: I think Pavlik is more alluding to the interface as in methods the client exposes not so much how the internal data model looks like Karol Szczepański: I thought about adding methods to simplify working with the hypermedia field ... but still expose it ... this object should help a client to get an overview what a resource is about elf Pavlik: Given that Karol didn't have the chance yet to reply to all comments I think we should move on ... that being said, I don't see it as being dangerous to attach more information to responses Karol Szczepański: I agree Topic: Use cases PR#132: use manages block to advertise type of collection members https://github.com/HydraCG/Specifications/pull/132 Markus Lanthaler: This is about describing to a client what it can expect in a collection ... there was some feedback that this is too much "RDF in your face" ... I share that concern but would like to proceed for it now ... as it solves the issue at hand and we can tweak it later Karol Szczepański: I share the criticism ... it looks a lot like reification would be enough ... I think this is about filtering, right? Markus Lanthaler: not exactly, this is about being able to tell a client which collection to choose if there are multiple candidates without having to mint custom properties to do so Karol Szczepański: I think specifying the class should be enough elf Pavlik: q Markus Lanthaler: how would you express that this is a collection about female people? Karol Szczepański: fair enough, but that goes into filtering I think ... that question is what we want to achieve elf Pavlik: I wanted to clarify that we considered to introduce something like memberType which solves exactly this issue - which I think is what Karol describes ... but we discovered that we already have the manages block so we can re-use something that we already agreed on ... if we don't like to go with this, we should re-open that discussion ... it's just a special case of an already existing feature ... if we want to have something more specific or general we can start from here and re-open the discussion ... the biggest benefit of this approach is that we don't need to require users to invent new terms like myvocab:event ... we can allow them to re-use existing terms from schema.org etc. ... so I'd like to to continue with this and take it from there ... we should then add more use cases that use the power this approach gives as (people attending an event e.g.) Markus Lanthaler: yeah, I completely agree ... karol, would that work for you? ... more concretely: merge this and then see if we can come up with something better later if we are unhappy with it Karol Szczepański: yes, that works for me PROPOSAL: Merge PR #132 that uses the manages block to advertise type of collection members Markus Lanthaler: +1 elf Pavlik: +1 Karol Szczepański: +1 RESOLUTION: Merge PR #132 that uses the manages block to advertise type of collection members Markus Lanthaler: I'll merge it after the meeting and then we can take it from there Markus Lanthaler: is there anything else you would like to discuss today? elf Pavlik: yes, I'd like to add some use cases ... which I hope will help to convey this feature better Markus Lanthaler: Pavlik, can you volunteer for this or would you like to discuss it first? elf Pavlik: If Karol is fine with it I can go ahead and add some use cases Karol Szczepański: do you want to replace events with people or do you want to add people? elf Pavlik: the latter, I'd like to add people without touching events Karol Szczepański: good idea. the more use cases the better ACTION: Pavlik to add some more use cases that illustrate the manages feature introduced in PR #132 Markus Lanthaler: anything else for today? elf Pavlik: https://github.com/HydraCG/Specifications/issues/134 elf Pavlik: I'd like to invite people to look at issue #134 ... it's about how to add existing resources to a collection Markus Lanthaler: I think there's an action item on Tomasz to see what APIs in the wild do about this ... which should help us to design this elf Pavlik: perhaps in the meantime we should add a use case for it Markus Lanthaler: as Karol said before, the more use cases the better ... so I'm all for it elf Pavlik: even if it's as early stage Markus Lanthaler: absolutely. use cases don't need to describe a solution ... just the problem. we can then work on a solution separately elf Pavlik: OK, I'll first work on my other action item and then create a use case for this too ACTION: Pavlik to create a use case for issue #134 (adding existing resources to collections)
Received on Monday, 21 August 2017 19:42:21 UTC