Hydra

Hydra W3C Community Group Telecon

Minutes for 2019-03-25

Karol Szczepański: Meeting: Hydra W3C Community Group Conference Call
Karol Szczepański is scribing.

Topic: Discuss open pull requests

Karol Szczepański: this one looks fine for me
Tomasz Pluskiewicz: there are no unresolved issues
Karol Szczepański: So I'll merge it ASAP
Add support for describing headers #185 https://github.com/HydraCG/Specifications/pull/185
Karol Szczepański: I've retracted template based features and now there are only simple expected/returned header names
Angelo Veltens: seems GH screwed the diff view
"returnsHeader": { "@id": "hydra:returnsHeader", "@type": "xsd:string" }, "expectsHeader": { "@id": "hydra:expectsHeader", "@type": "xsd:string" },
{ "@id": "hydra:returnsHeader", "@type": "rdf:Property", "label": "returns header", "comment": "Name of the header returned by the operation.", "domain": "hydra:Operation", "range": "xsd:string", "vs:term_status": "testing" }, { "@id": "hydra:expectsHeader", "@type": "rdf:Property", "label": "expects header", "comment": "Specification of the header expected by the operation.", [CUT]
```
Angelo Veltens: seems like broken line endings
Tomasz Pluskiewicz: when you looks at GH you can change display options
Karol Szczepański: I'll take a look at those line endings
Karol Szczepański: not sure what went wrong as I don't recall chaning anything by hand
Detailed specification for expects/returns and strongly typed collections #187 https://github.com/HydraCG/Specifications/pull/187
Karol Szczepański: I did oppose using SHACL to express constraints
Angelo Veltens: I understand you don't wanto commit hydra to specific solution
Angelo Veltens: but using self crafted elements might introduce more confusion
Tomasz Pluskiewicz: SHACL shouldn't be a core vocab
Tomasz Pluskiewicz: we should target a framework for extensions
Tomasz Pluskiewicz: we could have some basic constructs and an extension for SHACL
Angelo Veltens: I've rediscovered - another way of using hydra:expects
```"hydra:expects": { "@type": "Product", "hydra:supportedProperty": [ { "hydra:property": "name", "hydra:required": true, "defaultValue": "shot", "readOnlyValue": true } ] }
Tomasz Pluskiewicz: which section in the document would it be?
Karol Szczepański: I didn't introduce anything really new
Karol Szczepański: hydra:manages is subPropertyOf hydra:specifies and all the other constructs are the same
Karol Szczepański: this was due to fact that hydra:manages is bound to collection
Angelo Veltens: how client would benefit from this PR now
Karol Szczepański: the biggest value would be in expressing non-RDF resources via media type constraint
Angelo Veltens: I don't like the recursion for collection item types
Angelo Veltens: for media types I'd go with different solution and for constraints I'd go with cookbook and examples
Tomasz Pluskiewicz: It's not tha academic as Angelo said
Angelo Veltens: we shall discuss it better, with examples and different approaches
Allow returns/expects to be expressed in terms of a media type #186 https://github.com/HydraCG/Specifications/pull/186/files
ACTION: Karol_Szczepanski to create a cookbook example and documentation changes for #186
Angelo Veltens: maybe we should introduce expectsMediaType (as with expects or expectsHeader)
Karol Szczepański: what if there are both predicates for non-rdf resource
Karol Szczepański: i.e. expectsMediaType: image/jpeg and expects: schema:Image
Tomasz Pluskiewicz: we shoulnd't mix returns and expects
Tomasz Pluskiewicz: but it is a content negotiation
Tomasz Pluskiewicz: it's not for hydra to decide whether the image as jpg and rdf is conceptually the same
Tomasz Pluskiewicz: if the client encounteres a description with different representation they should be know on how to handle such a payload
Karol Szczepański: what would be meaning of this construct with both media type and RDF class expectation
Karol Szczepański: image and it's meta-data document are diferent resources
Angelo Veltens: for person you could have a schema:Person as a return/expect a resource describing it, either as HTML or RDF data
ACTION: Karol_Szczepanski close PR 186 and open a cookbook story with expectsMediaType/expects (and returns equiavelents)

Topic: Monitoring and handling of the @HydraCG Twitter account

Tomasz Pluskiewicz: I can tweet and reply to messages
Tomasz Pluskiewicz: for now I'm fine taking care of it alone
Tomasz Pluskiewicz: we've created a zapier account for HydraCG
ACTION: tpluskiewicz is to hookup slack with tweeter

Topic: Development of example API and client application

Karol Szczepański: I'm working on a hydr console angular app
Karol Szczepański: I've i.e. stumbled on an issue on which links to display
Angelo Veltens: we lack examples of server side payloads (without any specific underlying technology)
Karol Szczepański: I think we shall have a call in two weeks but I'm fine with next one