Hydra W3C Community Group Telecon
Minutes for 2018-03-05
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls#2018-03-05
- Topics
- Action Items
- Chair
- Markus Lanthaler
- Scribe
- Tomasz Pluskiewicz
- Present
- Markus Lanthaler, Tomasz Pluskiewicz, Thomas Bergwinkl, Karol Szczepański
- Audio Log
Tomasz Pluskiewicz is scribing.
Topic: Operation linked to class and property (ISSUE-156)
Thomas Bergwinkl: I commented on issue #156
... I changed the example to be easier to understand
... both can be POSTed and both go with a Comment
... I hope it's now easier
... you can use type to distinguish but because property is generated with, it generates two triples
Markus Lanthaler: so, 2 operations associated to same property
... but only appropriate on a single instance?
Thomas Bergwinkl: maybe people would like to have operation which description is only valid for a single class
... sometime you could control where you don't control the ontology
Markus Lanthaler: we'd need to introduce a way to specify operation both based on property and class
Markus Lanthaler: you wouldn't want to create sub property?
Thomas Bergwinkl: you could use OWL
... in general, when reusing ontology, you'd have that problem
Markus Lanthaler: do you think it should be supported?
Thomas Bergwinkl: yes, because people may expect that it should work based on examples
... maybe there are some reason not to use it this way or a better
... but it should be covered somehow
Markus Lanthaler: so main concern is confusion?
Thomas Bergwinkl: one is resue and second is JSON-LD making int possible
Markus Lanthaler: we should restrucutre to keep definition on class and restrict somehow
Thomas Bergwinkl: it may be a breaking change but I thought now is time to discuss
Markus Lanthaler: I quite like it
... so, you'd have the same operation on all classes
... we change operations quite a bit anyway. anyone disagrees?
Karol Szczepański: I thing it's a wider topic
... related to inheritance or overriding or forbidding/enforcing constructs
... maybe we need to be careful and not come up with quick solution
... we will need a way to define what is allowed and what is not
Tomasz Pluskiewicz: I was thinking of putting it on its head and use multiple classes instead of attaching the operation to the property [scribe assist by Markus Lanthaler]
Markus Lanthaler: it's just selective
Markus Lanthaler: ... Markus, in the past you were strongly against forbidding and overriding operations?
Markus Lanthaler: yes, I still am. I don't want to allow to override stuff [scribe assist by Markus Lanthaler]
... this here is not allowing it in the first place
Tomasz Pluskiewicz: it's either inclusive or decalred multiple times
Markus Lanthaler: i'd prefer declaring multiple times
Thomas Bergwinkl: I could provide more examples
Markus Lanthaler: are you aware of past discussions
Thomas Bergwinkl: no, I need more hints to research those discussions
Markus Lanthaler: in the past we discussed how you can delete entities
... but sometimes you can't
... one way is to invalidate that (forbidding)
... the overriding is to override the `expects` in a child class
... I'm still against because it's not like RDF works
... your proposal is slightly different
Thomas Bergwinkl: other stuff could be implemented with SHACL?
Markus Lanthaler: maybe. problem is that you can have multiple documents
Thomas Bergwinkl: with SHACL you can make constrain is operation is allowed
... just came to my mind
Karol Szczepański: can we come up with a use case like before
Markus Lanthaler: isn't that what Thomas did?
Karol Szczepański: yes, but with use case we could have some more request/response with more detail
Karol Szczepański: https://github.com/HydraCG/Specifications/blob/master/drafts/use-cases/3.obtaining-events.md
Markus Lanthaler: we can move this to a UC document. would you be able Thomas?
Markus Lanthaler: nothing fancy. markdown with some example
Thomas Bergwinkl: I can do that. I have to go now
ACTION: Thomas to convert ISSUE-156 into a use case document
Markus Lanthaler: we have 3 open PRs
... PR-157 doesn't need much discussion
Karol Szczepański: it was quite silent.
... I just added some changes to @context. just adding stuff marked as resolved
Topic: Added new vocabulary elements (PR-157)
Karol Szczepański: memberTemplate maybe is not ready to be merged?
Tomasz Pluskiewicz: this property looks redundant when we decide on action/operation changes
Markus Lanthaler: it might
Karol Szczepański: I'm not sure
... I don't see special benefit of actions. the target is still tied to operation
... the benefit is only the type
Markus Lanthaler: the diff is that you would associate action with resource
... currently the operation always applies to the subject
Karol Szczepański: the action itself doesn't add much
Tomasz Pluskiewicz: action may improve discoverabiliy
Karol Szczepański: actions still doesn't resolve template
Tomasz Pluskiewicz: what issue with template?
Karol Szczepański: how the client knows that a template is used to retrieve collection member?
Markus Lanthaler: the action would tell you that
Karol Szczepański: is that included in schema.org?
... I'd rather use something from hydra rather then external concept
... and we still lack the connection between the collection and the member
... I think we still need some direct semantic
... for the time being I will retract memberTemplate from #157
Markus Lanthaler: yes, we should split the PR in two
Topic: Introduced a collections helper property on IHypermediaContainer (Heracles/PR-27)
Markus Lanthaler: https://github.com/HydraCG/Heracles.ts/pull/27
Markus Lanthaler: could you give an overview, Karol?
Karol Szczepański: https://github.com/HydraCG/Specifications/issues/155
Karol Szczepański: this issue discussed the `collection` predicate
... I implemented a helper which allows accessing collection from any resource
Markus Lanthaler: there are some question
Karol Szczepański: yes, I haven't had the time yet to reply
Tomasz Pluskiewicz: do we really want collection on every resource?
Markus Lanthaler: usually would be empty
Karol Szczepański: the vocabulary doesn't define any domain
... like other terms within the vocabulary
Tomasz Pluskiewicz: would I check `collection` every time?
Markus Lanthaler: if you wanted to crawl everything, maybe yes
... but usually you would have a goal and won't have to
Karol Szczepański: my driver is that hydra:Resource currently have the operation predicate
... and it was natural that if I have operations and link, I would have collections
... let's move this to github
Markus Lanthaler: yes, otherwise it's rather uncontroversial. we can merge later
Karol Szczepański: I was thinking about a roadmap
... the development seems slower than expected
Topic: Velocity
... there are only two use cases and pretty simple
... we could come up with improvement to the client
... we could add some ability to inject header, etc. like with fetch
Markus Lanthaler: so it's roadmap for heracles or vocabulary?
Karol Szczepański: both. they cannot be developed in disconnect
... I would create a backlog of ideas for implementation
Markus Lanthaler: the client can currently work with templated links, operations, collections?
... what else is still missing?
Karol Szczepański: documentation part
Markus Lanthaler: what do you mean. ApiDocumentation is ignored?
Karol Szczepański: we do have it but it's not implemented well
... the specs seem incomplete
Markus Lanthaler: this would be a good item
... do you want us to write it down?
Karol Szczepański: we could try more use cases
Tomasz Pluskiewicz: we need to battle test heracles
Karol Szczepański: do we have a real project?
Markus Lanthaler: there is the issue tracker
Tomasz Pluskiewicz: I have the client I was building: http://hydra-polymer.herokuapp.com
... it's using the other library
... we could try to replace it with heracles.ts
Markus Lanthaler: it is a good idea and we could include snippets for people to explore
... does this answer you question?
Karol Szczepański: I'll try to come up with some use cases first
... supported operations/properties are coming from Api Documentation, right?
... that would be what I'd work on