Re: Moving forward

Yes, that's right. Nothing changes in that matter

Karol

niedz., 6 sty 2019, 15:06: Tomasz Pluskiewicz <tomasz@t-code.pl> napisał(a):

> 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
> >
>
>
>