Hydra W3C Community Group Telecon

Minutes for 2017-06-26

elf Pavlik is scribing.

Topic: Status update on architectural diagram

Markus Lanthaler: ruben made PR and send an email that he can not join the call today
... PR includes script that generates SVG from LaTeX on travis and adds it to gh-pages branch
... we should just probably move this discussion to PR or mailing list

Topic: schema.org actions PR #125

elf Pavlik: I think I addressed all feedback [scribe assist by Markus Lanthaler]
... I touched a few more things than just schema.org actions
... one thing is, e.g. the #events link
PROPOSAL: Merge schema.org actions PR #125
Markus Lanthaler: +1
elf Pavlik: +1
Karol Szczepański: +1
RESOLUTION: Merge schema.org actions PR #125
Markus Lanthaler: I will merge it after the meeting

Topic: Reference client PR #1

Markus Lanthaler: karol would you like to give us quick update ?
Karol Szczepański: I made new commit yesterday which addressed most of the feedback
... I still don't have this 'lazy parsing', possibly I would leave it for the future
... up to you (Markus) if you need it now or we can wait
Markus Lanthaler: I don't see it as blocking issue
Karol Szczepański: everything now stays behind interfaces facade so we can replace everything behind it later
Markus Lanthaler: did you already add a TODO ?
Karol Szczepański: in general i try to stick to the Use Cases
... currently we have a little bit of implementation
... ApiDocumentation fetching and EntryPoint fetching
... we should have some integration tests based on Ucs
... i would like to root it in the use cases
Markus Lanthaler: I meant just a comment with TODO just as a reminder for what we discussed and decided to address in the future
Karol Szczepański: we can also create issues in the gh repo
Markus Lanthaler: creating an issue sounds like a good way to go
... in general if someone creates PR and we want to defer addressing some of the issues, creating gh issues makes sense
Karol Szczepański: I'll create issues for what we want to deffer from this PR
Markus Lanthaler: I find it difficult to track of all those comments we make in PR reviews
... do you know any other tool that might handle it better
... if author of the PR could mark a thread as addressed or not
... i could suggest something after small research
ACTION: Markus will try to find a tool which will help us with PR reviews; it's currently difficult to keep track what has been addressed and what hasn't
Karol Szczepański: one question regarding my PR
... this 10 days long discussion stops me from further development
... how we can speed up our PR process so it doesn't block my development
... from my perspective current pace feels slow
... waiting 10 days seems to long
Markus Lanthaler: maybe making smaller PRs will make things faster
... this one as initial one included a lot of things
... if you nail down interfaces first, which requires most discussion
and focus on implementation later this would speed things up
Karol Szczepański: IMO our needs have to be a driver, it may benefit a final outcome if requirements drive it
Markus Lanthaler: interfaces could be driven by use cases, what user of this library would need to work with given use case
Karol Szczepański: i'll try to think it over and will propose something to the community
Markus Lanthaler: what next things you would like to work on?
Karol Szczepański: i would like to start with integration tests, and add datasets based on our use cases
... so that we can start extracting some data that other implementations could eventually also use
Markus Lanthaler: given we didn't come up with a specific solution on how to speed it up, maybe also you could ask on mailing list for reviews
and when you see it ready to merge we can make a 'last call' on mailing list to ask if anyone objects
elf Pavlik: I think if we get disciplined and keep focused in PRs we could get much faster [scribe assist by Markus Lanthaler]
... we shouldn't get sidetracked by unrelated stuff but move that aggresively to separate issues
Karol Szczepański: we should try everything what could speed up the process

Topic: void:classPartition Issue #126

elf Pavlik: I'm not sure this is worth discussing yet but given we have time... [scribe assist by Markus Lanthaler]
... I think we should find a better pattern for links in the EntryPoint that point to collections of resources of a specific type
... the example was the "events" link in the EntryPoint that points to a collection containing all Events
... we need to be able to describe that to a client in a better way
Karol Szczepański: We discussed this before in the context of Data Shapes [scribe assist by Markus Lanthaler]
... OWL would be another solution
... but it opens a can of worms and may be difficult for the client to use
Karol Szczepański: SHACL was the name
Markus Lanthaler: OWL works and has capacity to express it, but it opens a can of worms that it has a lot of power and clients should have to fully implement it
... class partition seems nice, but hydra should handle it natively give as common use case in APIs
... we should investigate options of nice short pattern
Markus Lanthaler: we could use issue #126 to discuss it in more detail
elf Pavlik: I'll post a link how SOLID solves this [scribe assist by Markus Lanthaler]
... OWL has something but it doesn't seem practical in real world scenarios
... we should come up with a better solution
ACTION: Markus to rename issue #126 to not suggest a solution
ACTION: Pavlik to drive discussion regarding #126 after the issue has been renamed
elf Pavlik: Currently the use case is only events [scribe assist by Markus Lanthaler]
... if there would be two or more types the problem would become more apparent
... Karol, what do you think about extending the use cases to show this?
Karol Szczepański: Sure, I'm open to extending the use cases [scribe assist by Markus Lanthaler]
Markus Lanthaler: anything else you would like to discuss today? we still have 30min