- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Tue, 15 Jan 2019 20:08:07 +0100
- To: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Cc: Angelo Veltens <angelo.veltens@online.de>, Hydra <public-hydra@w3.org>
Dear all Find this mail as a brief summary of actions taken on the enlisted GitHub issues: Closed: #20 Ideas for additional features/vocabularies #31 Are Operations violating REST's uniform interface constraint? #38 Define "priority of constituencies" #40 Reversed SupportedProperty #44 Restructure spec to talk about application state, resource state, and API as whole #51 Improve definition of hydra:search #65 Create a test suite for servers of triple pattern fragments #70 Description of workflows #74 Add support for examples #77 Triple pattern fragments: explain how to handle blank nodes #91 How to suggest dereferenceability? #93 Clarify the reuse of the request URL inside of the fragment #98 Add picture to LDF/TPF specs #109 Use W3C HTTP RDF vocabulary Left opened - more discussion is needed: #56 Date ranges / intervals for LDF - the issue was initially closed, but due to demands, I've reopened it - feel free to elaborate more on GH #147 Start a Hydra gitbook - it came out on the first telco, that we may neeed a gitbook, thus first steps are being taken to make it happen #39 Document how "errors" can be given an identifier and be reused in responses - initially marked for resolution, but it is still in progress #45 Introduce hydra:filter (subPropertyOf hydra:search) - initially marked for resolution but it seems we've got lost in discussions - unsure on how to proceed #78 Spec document has wrong header level for classes and properties - initially marked for resolution but it's still in progress #82 Add support for allowed literals and allowed individuals - initially marked for resolution but it's still in progress #101 Create Hydra specification from JSON example - initially marked for resolution but it's still in progress Resolved (may require some spec changes): #1 Allow SupportedProperty to overwrite a vocabulary's rdfs:label and rdfs:comment - PR173 #15 Define a property to be used for untyped links? - PR174 #28 Should properties and types that only differ in their capitalization be avoided? - closed without any action #32 Should hydra:returns and hydra:statusCodes be removed to avoid tight coupling? - PR175 #48 Add domainIncludes/rangeIncludes statements - PR176 #69 Describe entry point -> ApiDocumentation flow - PR177 #72 Discuss versioning - PR179 As for the resolved - you may treat those pull requests as a call for consensus - feel free to provide any feedback after review so we can actually close these. Regards Karol Szczepanski pon., 7 sty 2019 o 13:06 Tomasz Pluskiewicz <tomasz@t-code.pl> napisał(a): > > NIce, thanks Angelo! > > @Karol, do you have admin access to GitHub organization already? I propose using using labels to easily organise and manage the decision we make about each issue. > > Best, > Tom > > > On 7 Jan 2019, at 12:56, Angelo Veltens <angelo.veltens@online.de> wrote: > > > > > > Am 01.01.19 um 20:07 schrieb Karol Szczepański: > >> 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" > >> [...] > > > > > > I published this list, including links to the issues here: > > > > https://angelo.veltens.org/public/hydra/issues.html > > > > > > Kind regards, > > Angelo > > > > > > >
Received on Tuesday, 15 January 2019 19:08:40 UTC