Moving forward

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 Tuesday, 1 January 2019 19:07:52 UTC