Hydra W3C Community Group Telecon
Minutes for 2017-08-21
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls
- Topics
- Resolutions
- Action Items
- Chair
- Markus Lanthaler
- Scribe
- Markus Lanthaler
- Present
- Markus Lanthaler, Karol Szczepański, elf Pavlik
- Audio Log
Markus Lanthaler is scribing.
Topic: Heracles.ts PR#11: Implementation necessary to achieve use case 3 - obtaining events
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
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: 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)
elf Pavlik: present+