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

Re: Organizing GitHub issues, projects and milestones for work on Profiles

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 16 May 2018 15:58:18 +0200
To: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <6471e167-8db4-d414-3fba-9e43ece0b286@kcoyle.net>
I will push back on the use of dct:conformsTo as a link to the profile
description document. dct:conformsTo is specifically about conforming to
a standard, and there is no reason to declare profile descriptions
"standards" in the sense intended by dct. In fact, profiles could be ad
hoc. Semantically, using dct:conformsTo for both a dataset conforming
to, for example, an ISO standard, and for a document that describes a
profile created by a single community would water-down the meaning of
dct:conformsTo and, IMO, wouldn't be at all useful. I could see a
motivation to have a property that specifically identifies a profile
that carries the definition of the data or metadata of a dataset.

kc

On 5/15/18 9:37 AM, Rob Atkinson wrote:
> It will be the profile, which may be described by ProfileDesc, by making
> the target profile an instance of prof:Profile and using the properties
> defined.
> 
> I think that a misunderstanding keeps sneaking in that a resource
> defining constraints "is the profile" - but whilst it _may_ in some
> cases completely describe a profile, in most cases it is only part of
> the profile definition, sometime normative and sometimes informative.
> Look at the DCAT-AP where a SHACL document is in development to assist
> in validation of conformance of DCAT-AP. 
> 
> If this is kept clear in our minds that we need to support common
> practices then the profile negotiation and DCAT have a very simple
> relationship, in the use of prof:Profile as the target for
> dct:conformsTo properties of Distributions.  ProfileDesc then adds two
> very specific capabilities - the ability to understand conformance in a
> hierarchy of specialised profiles and the ability to discover things
> like SHACL documents, guidance, examples and everything else we are
> seeing in practice (c.f. Makx's example of the DCAT-AP with its
> documents described as "Distributions". Profiles are not really
> "Datasets" - but if we generalise the concept of a catalogued resource,
> then prof:resource may be a sub:property of dcat:distribution.  (I quite
> like this view as it makes catalogueing of profiles a natural thing -
> which it should be as an "agreement" it needs to be registered and
> shared... - it hopefuilly will also stop people conflating one or more
> partial implementations with the thing itself - its the same pattern ad
> Dataset-Distribution we are comfortable with. )
> 
> 
> 
> 
> 
> 
> On 15 May 2018 at 16:55, Svensson, Lars <L.Svensson@dnb.de
> <mailto:L.Svensson@dnb.de>> wrote:
> 
>     On Friday, May 11, 2018 9:26 AM, Karen Coyle
>     [mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>] wrote:
> 
>     > Antoine, we already have profile negotiation as a deliverable, and the
>     > advice from Lars is that the deliverable would depend on a very limited
>     > requirement that the profile have a IRI. I suspect that we need,
>     > however, to look at that again in light of profileDesc - in the sense of
>     > it isn't clear to me if the IRI in question is for the profile or the
>     > profileDesc. So there is going to be a teasing out of relationships
>     > between profile negotiation and profileDesc.
> 
>     In my world it's the IRI of the profile, not of the profileDesc
>     (just as we usually refer to entities and not just to their
>     descriptions).
> 
>     > Note that the current editors draft for the Guidance document has the
>     > editors listing that should be on the Negotiation document. It would be
>     > good to set up the separate projects, and we need a new draft document
>     > for negotiation. Where we slot in profileDesc - whether in Guidance or a
>     > separate document - seems to still be an open question.
>     > 
>     > Are you familiar enough with Respec to at least get the document folders
>     > set up and the negotiation editors moved to the correct document? Or is
>     > there someone reading this who will volunteer for that? (Since you are
>     > on vacation.)
> 
>     If we can agree on a name for the folder of the negotiation document
>     ('profile-negotiation'?) I can take care of moving the current
>     negotiation-centric files to that document. If I need W3C guidance I
>     can probably refer to Iván Hermann whom I'm likely to meet tomorrow.
> 
>     Best,
> 
>     Lars
>      
>     > On 5/9/18 3:15 PM, Antoine Isaac wrote:
>     > > Hi,
>     > >
>     > > Following today's discussion on the profile work [6] and my
>     action on
>     > > labels [7] I would like to come back to Simon's suggestions from the
>     > > thread below, so that we can set up our space for working on all
>     > > profiles deliverables.
>     > >
>     > > Simon has suggested to create Github projects [4] for each
>     deliverable
>     > > and I agree with him. What I can do is create one project for
>     each of
>     > > the deliverables we envision in relation with profiles:
>     > > - profile negotiation
>     > > - profile guidance
>     > > - profile description vocabulary
>     > >
>     > > The next step would be to check the content of a current project
>     > > "Guidance for Application Profiles for Dataset Exchange" [8] and
>     see how
>     > > to distribute its content onto the three new projects. It seems that
>     > > this project gathers issues that are related to all three
>     deliverables.
>     > >
>     > > @Simon, would it sound ok? Is it something we could try to do
>     together?
>     > >
>     > > The next step would be to see whether we need to organize
>     further our
>     > > work with Github milestones [2]. I have created 3 of them for
>     the FPWDs
>     > > of the profile deliverables [9]. These are currently empty, and I
>     > > hesitate to fill them until the group agrees we need them.
>     > > As a matter of fact Simon has already created milestones at [2]
>     and I
>     > > don't know what they correspond to. They don't have due dates,
>     and look
>     > > rather like aspects of deliverables. Simon himself said they hadn't
>     > > helped much. Should we delete them, in the light of coming Github
>     > > projects and possibly new milestones with due dates [9]?
>     > >
>     > > Best,
>     > >
>     > > Antoine
>     > >
>     > > [6] https://www.w3.org/2018/05/09-dxwg-minutes#item01
>     <https://www.w3.org/2018/05/09-dxwg-minutes#item01>,
>     > > https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
>     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP->
>     > Gks5dDa8n2B5IN6rWa3kRpo/
>     > >
>     > > [7] https://www.w3.org/2017/dxwg/track/actions/109
>     <https://www.w3.org/2017/dxwg/track/actions/109>
>     > > [8] https://github.com/w3c/dxwg/projects/2
>     <https://github.com/w3c/dxwg/projects/2>
>     > > [9] https://github.com/w3c/dxwg/milestone/9
>     <https://github.com/w3c/dxwg/milestone/9>,
>     > > https://github.com/w3c/dxwg/milestone/10
>     <https://github.com/w3c/dxwg/milestone/10>,
>     > > https://github.com/w3c/dxwg/milestone/11
>     <https://github.com/w3c/dxwg/milestone/11>
>     > >
>     > >
>     > > On 27/04/18 02:25, Rob Atkinson wrote:
>     > >> Hi - have been using Git projects in the OGC work I'm doing to help
>     > >> organise and visualise at lerast some minimal sense of
>     priortisation.
>     > >> Kanban doesnt really help you much with dependencies - unless you
>     > >> create a column explicitly for "waiting on other issues to unblock"
>     > >>
>     > >> You can have issues appearing in multiple projects - so that seems
>     > >> OK.  Its not a high overhead and does give a visual feel, so it at
>     > >> least will help the coordinators with prioritisation I feel.
>     > >>
>     > >> Rob
>     > >>
>     > >>
>     > >> On 27 April 2018 at 08:52, <Simon.Cox@csiro.au
>     > >> <mailto:Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>> wrote:
>     > >>
>     > >>     I fear the labels' horse has bolted.
>     > >>     Earlier this week I deleted all the unused labels (about
>     10) but
>     > >> there are still a lot. Labels, like tags, are primarily for recall.
>     > >>
>     > >>     Perhaps use of milestones for precise grouping? I made up a
>     few,
>     > >> but so far they mostly reflect my biases, plus observations of some
>     > >> hot topics.
>     > >>
>     > >>     -----Original Message-----
>     > >>     From: Karen Coyle [mailto:kcoyle@kcoyle.net
>     <mailto:kcoyle@kcoyle.net>
>     > >> <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>]
>     > >>     Sent: Thursday, 26 April, 2018 01:55
>     > >>     To: public-dxwg-wg@w3.org <mailto:public-dxwg-wg@w3.org>
>     <mailto:public-dxwg-wg@w3.org <mailto:public-dxwg-wg@w3.org>>
>     > >>     Subject: Re: Organizing the issues - GitHub Projects?
>     > >>
>     > >>     Regardless of whether we opt to use projects, would there be an
>     > >> advantage to making stricter use of the labels? Or creating labels
>     > >> that are only used to identify deliverables? It seems to me
>     that the
>     > >> labels we have are being used pretty loosely, which is good for
>     recall
>     > >> but less so for precision. A few precise labels might help with the
>     > >> organizing?
>     > >>
>     > >>     kc
>     > >>
>     > >>     On 4/24/18 7:43 PM, Simon.Cox@csiro.au wrote:
>     > >>      > The list of issues on our GitHub is getting quite
>     overwhelming
>     > >> [1].
>     > >>      >
>     > >>      > A few weeks ago I proposed that we make some groupings using
>     > >> GitHub's
>     > >>      > Milestones and set up a few [2] but this doesn't appear
>     to have
>     > >> helped
>     > >>      > much.
>     > >>      >
>     > >>      > Effectively the Milestones are just a kind of glorified tag
>     > >> (label).
>     > >>      >
>     > >>      > And we definitely have too many tags (labels) [3].
>     > >>      >
>     > >>      >
>     > >>      >
>     > >>      > So, here's another suggestion: create a GitHub Project
>     for each
>     > >>      > deliverable [4].
>     > >>      >
>     > >>      > GitHub "Projects" provides a rudimentary Kanban board
>     for each
>     > >>      > project, allowing issues to be sorted in status ("todo", "in
>     > >> progress", "done") [5].
>     > >>      >
>     > >>      > It seems to correspond pretty well with deliverables,
>     and at least
>     > >>      > will allow us to look at the issues associated with the
>     separate
>     > >>      > deliverables more cleanly.
>     > >>      >
>     > >>      >
>     > >>      >
>     > >>      > Any comments?
>     > >>      >
>     > >>      >
>     > >>      >
>     > >>      > [1] https://github.com/w3c/dxwg/issues
>     <https://github.com/w3c/dxwg/issues>
>     > >> <https://github.com/w3c/dxwg/issues
>     <https://github.com/w3c/dxwg/issues>>
>     > >>      >
>     > >>      > [2] https://github.com/w3c/dxwg/milestones
>     <https://github.com/w3c/dxwg/milestones>
>     > >> <https://github.com/w3c/dxwg/milestones
>     <https://github.com/w3c/dxwg/milestones>>
>     > >>      >
>     > >>      > [3] https://github.com/w3c/dxwg/labels
>     <https://github.com/w3c/dxwg/labels>
>     > >> <https://github.com/w3c/dxwg/labels
>     <https://github.com/w3c/dxwg/labels>>
>     > >>      >
>     > >>      > [4] https://github.com/w3c/dxwg/projects
>     <https://github.com/w3c/dxwg/projects>
>     > >> <https://github.com/w3c/dxwg/projects
>     <https://github.com/w3c/dxwg/projects>>
>     > >>      >
>     > >>      > [5]
>     https://help.github.com/articles/about-project-boards/
>     <https://help.github.com/articles/about-project-boards/>
>     > >> <https://help.github.com/articles/about-project-boards/
>     <https://help.github.com/articles/about-project-boards/>>
>     > >>      >
>     > >>      >
>     > >>      >
>     > >>      > *Simon J D Cox *
>     > >>      >
>     > >>      > Research Scientist - Environmental Informatics
>     > >>      >
>     > >>      > Team Leader - Environmental Information Infrastructure
>     > >>      >
>     > >>      > CSIRO Land and Water <http://www.csiro.au/Research/LWF
>     <http://www.csiro.au/Research/LWF>
>     > >> <http://www.csiro.au/Research/LWF
>     <http://www.csiro.au/Research/LWF>>>
>     > >>      >
>     > >>      >
>     > >
>     > >
>     >
>     > --
>     > Karen Coyle
>     > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     > m: 1-510-435-8234 (Signal)
>     > skype: kcoylenet/+1-510-984-3600
> 
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 16 May 2018 13:58:50 UTC

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