W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2018

Re: Requirements --> GitHub issues

From: Jaroslav Pullmann <jaroslav.pullmann@fit.fraunhofer.de>
Date: Thu, 18 Jan 2018 09:30:39 +0100
To: "Alejandra Gonzalez-Beltran" <alejandra.gonzalezbeltran@oerc.ox.ac.uk>
Message-ID: <21f6-5a605b00-33-4a4e4100@250989251>
Cc: "Rob Atkinson" <rob@metalinkage.com.au>, Simon.Cox@csiro.au, public-dxwg-wg@w3.org

  Dear Alejandra, 

     thank you, there are no real challenges, but time. I am now blocked in a full day meeting and will resume tomorrow. 
   My idea was to port the whole requirement <section> making GitHub issue tracker an intermediate, rich editor. This  would 
   allow re-importing into the UCR document. My little testing was positive - GithHub REST API really easy to use, the issue
   editor accepts, displays and persists rich HTML content:

        https://github.com/w3c/dxwg/issues/51
        https://api.github.com/repos/w3c/dxwg/issues/51  

   Would you agree to proceed in this way?
    Best regards
  Jaro
 
On Wednesday, January 17, 2018 22:17 CET, Alejandra Gonzalez-Beltran <alejandra.gonzalezbeltran@oerc.ox.ac.uk> wrote: 
 
> Hi Jaro,
> 
> It's great that you're looking into the automated creation of issues for 
> each of the requirements.
> 
> In case you are also looking at the tagging, I have added labels for 
> each of the requirements' categories:
> 
> https://github.com/w3c/dxwg/labels
> 
> Let us know how you get on.
> 
> Best wishes,
> 
> Alejandra
> 
> 
> On 17/01/2018 15:25, Jaroslav Pullmann wrote:
> >    Hello Simon,  hello Rob
> >
> >      thank you, the example is really useful! I've entered a long distance train, a reason I'll probably miss today's DCAT call
> >    but a chance to dedicate time on the requirement conversion.  As mentioned by Rob, the GitHub REST API is the right tool
> >    (which I have to familiarize with first). The import should be done by Friday/next Monday.
> >
> >     Best regards
> >   Jaro
> >
> >
> > On Wednesday, January 17, 2018 07:14 CET, Rob Atkinson <rob@metalinkage.com.au> wrote:
> >   
> >> Was hoping that Jaro would be able to adapt his scripts to pump out all the
> >> issues to github via the REST api :-)
> >>
> >> rob
> >>
> >>
> >> On Wed, 17 Jan 2018 at 16:15 <Simon.Cox@csiro.au> wrote:
> >>
> >>> OK folk, I broke down and did one manually to illustrate what I was hoping
> >>> could be done automatically.
> >>>
> >>>
> >>>
> >>> https://github.com/w3c/dxwg/issues/50 corresponds to
> >>> https://www.w3.org/TR/dcat-ucr/#RDID
> >>>
> >>>
> >>>
> >>> I copied the link to the UCR document into the issue.
> >>>
> >>> I gave it the following labels
> >>>
> >>> (i)                  [requirement]
> >>>
> >>> (ii)                [dcat] according to the deliverable-related tag
> >>> inherited from Use Case that generated the requirement
> >>>
> >>>
> >>>
> >>> Putting it in a standard issue-tracker allows us to follow the progress of
> >>> satisfying this requirement, or re-classifying it by changing the labels
> >>> (tags) if necessary.
> >>>
> >>> I just used the text from the UCR document directly, which includes the
> >>> sub-heading number (6.1.1 in this case) which may be non-persistent if the
> >>> UCR document is revised. On the other hand, the code [RDID] is also
> >>> visible, which I think was intended to be a persistent identifier.
> >>>
> >>>
> >>> This issue is now found by a standard query for
> >>>
> >>> -          Issues tagged [dcat]
> >>>
> >>> o
> >>> https://github.com/w3c/dxwg/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Adcat+
> >>>
> >>>
> >>> -          Issues tagged [dcat] and [requirement]
> >>>
> >>> o
> >>> https://github.com/w3c/dxwg/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Arequirement+label%3Adcat+
> >>>
> >>>
> >>>
> >>>
> >>> I also see that Jaro has done a lot of clever Javascripting to get similar
> >>> selection functions into the UCR document itself
> >>>
> >>> https://www.w3.org/TR/dcat-ucr/#Tags but I suggest that if we can use a
> >>> generic tool (GitHub) which also does the dynamic record-keeping, then
> >>> maybe we can reduce the need for bespoke scripting moving forward.
> >>>
> >>>
> >>> Simon
> >>>
> >>>
> >>>
> >>> *Simon J D Cox *
> >>>
> >>> Research Scientist
> >>>
> >>> Environmental Informatics
> >>>
> >>> CSIRO Land and Water <http://www.csiro.au/Research/LWF>
> >>>
> >>>
> >>>
> >>> *E* simon.cox@csiro.au *T* +61 3 9545 2365 <(03)%209545%202365> *M* +61
> >>> 403 302 672 <0403%20302%20672>
> >>>
> >>>     *Mail:* Private Bag 10, Clayton South, Vic 3169
> >>>
> >>> *   Visit: *Central Reception, Research Way, Clayton, Vic 3168
> >>>
> >>> *   Deliver: *Gate 3, Normanby Road, Clayton, Vic
> >>> <https://maps.google.com/?q=3,+Normanby+Road,+Clayton,+Vic&entry=gmail&source=g>
> >>> 3168
> >>>
> >>> people.csiro.au/Simon-Cox
> >>>
> >>> orcid.org/0000-0002-3884-3420
> >>>
> >>> researchgate.net/profile/Simon_Cox3
> >>> <https://www.researchgate.net/profile/Simon_Cox3>
> >>>
> >>> github.com/dr-shorthair
> >>>
> >>> lov.okfn.org/dataset/lov/agents/Simon%20Cox
> >>>
> >>> @dr_shorthair <https://twitter.com/dr_shorthair>
> >>>
> >>> https://xkcd.com/1810/
> >>>
> >>>
> >>>
> >>> *PLEASE NOTE*
> >>>
> >>> The information contained in this email may be confidential or privileged.
> >>> Any unauthorised use or disclosure is prohibited. If you have received this
> >>> email in error, please delete it immediately and notify the sender by
> >>> return email. Thank you. To the extent permitted by law, CSIRO does not
> >>> represent, warrant and/or guarantee that the integrity of this
> >>> communication has been maintained or that the communication is free of
> >>> errors, virus, interception or interference.
> >>>
> >>>
> >>>
> >>> *Please consider the environment before printing this email.*
> >>>
> >>>
> >>>
> >>>
> >>>
> >   
> >   
> >   
> 
 
 
 
-- 
Jaroslav Pullmann
Fraunhofer Institute for Applied Information Technology FIT
User-Centered Ubiquitous Computing
Schloss Birlinghoven | D-53757 Sankt Augustin | Germany
Phone: +49-2241-143620 | Fax: +49-2241-142146 
Received on Thursday, 18 January 2018 08:31:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:57 UTC