Re: Moving forward

Hey Karol

I understand that we’re reusing the same uberconference and time slot as usually?

Tom

> On 1 Jan 2019, at 20:07, Karol Szczepański <karol.szczepanski@gmail.com> wrote:
> 
> Happy New Year hydranians!
> 
> It took some time, but finally a bright light in the tunnel is in
> sight (and no, it is not a train).
> 
> After some analysis, it seems that there are 16 Hydra-spec GitHub
> issues are somehow obsolete, 12 are somehow resolved and either
> require no further action or some minor spec change (both listed
> below).
> 
> I'd like to setup a call on next Monday, 7th of January 2019 so we can
> agree (or not?) to close those and on how to move forward with more
> urgent matters.
> 
> In general - after reviewing all issues an image of these features emerges:
> - examples and spec's shape in general
> - collections (filtering, linking, etc) - never ending story :)
> - API documentation
> - complete request's shape - parameters, templates, actions,
> operations and theory of everything (I was using this term "shape" for
> some time but I'm opened for alternatives - it collides with SHACL)
> 
> Don't hesitate to share your thoughts on what topics should be covered
> in that call
> 
> I'll try to prepare a PR that should cover all those "resolved" issues
> with spec changes, but feel free to grab any of the issues and work on
> them!
> 
> Regards
> 
> Karol Szczepański
> 
> PS. Thanks Tomasz for helping me with the review!
> 
> -------------------------
> 
> Obsolete:
> 
> #20 Ideas for additional features/vocabularies -> I believe whole
> GitHub and community is for suggesting features!
> #31 Are Operations violating REST's uniform interface constraint?
> #38 Define "priority of constituencies"
> #40 Reversed SupportedProperty -> in general, reversed logic makes
> clients difficult to implement
> #44 Restructure spec to talk about application state, resource state,
> and API as whole -> our further spec work will evolve it
> #51 Improve definition of hydra:search -> related to #48
> #56 Date ranges / intervals for LDF -> seems to be out of scope of Hydra
> #65 Create a test suite for servers of triple pattern fragments ->
> this also seems to be out of scope of Hydra
> #70 Description of workflows -> we can always reopen this once we're
> done with some more important tasks
> #74 Add support for examples -> as with #44, our further work should
> improve it in general; also we've got some use cases in the repo
> #77 Triple pattern fragments: explain how to handle blank nodes -> out
> of scope of Hydra)
> #91 How to suggest dereferenceability? -> out of scope of Hydra
> #93 Clarify the reuse of the request URL inside of the fragment -> out
> of scope of Hydra
> #98 Add picture to LDF/TPF specs -> out of scope of Hydra
> #109 Use W3C HTTP RDF vocabulary -> I believe this would impose a
> tight coupling to HTTP, which is not the case here; Hydra was supposed
> to be protocol agnostic
> #147 Start a Hydra gitbook -> further spec work should clarify things
> 
> Resolved (may require some spec changes):
> 
> #1 Allow SupportedProperty to overwrite a vocabulary's rdfs:label and
> rdfs:comment
> #15 Define a property to be used for untyped links?
> #28 Should properties and types that only differ in their
> capitalization be avoided? -> no action needed
> #32 Should hydra:returns and hydra:statusCodes be removed to avoid
> tight coupling? -> related to #88, no action needed
> #39 Document how "errors" can be given an identifier and be reused in responses
> #45 Introduce hydra:filter (subPropertyOf hydra:search)
> #48 Add domainIncludes/rangeIncludes statements
> #69 Describe entry point -> ApiDocumentation flow
> #72 Discuss versioning
> #78 Spec document has wrong header level for classes and properties
> #82 Add support for allowed literals and allowed individuals
> #101 Create Hydra specification from JSON example
>

Received on Sunday, 6 January 2019 14:07:32 UTC