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

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

From: <andrea.perego@ec.europa.eu>
Date: Thu, 17 May 2018 07:23:55 +0000
To: <kcoyle@kcoyle.net>, <Simon.Cox@csiro.au>, <public-dxwg-wg@w3.org>
Message-ID: <EDFF15E839F79242AA55B1468C63DDA908DC549F@S-DC-ESTG02-J.net1.cec.eu.int>
Hi, Karen.

I must confess I'm still unclear whether the notion of "profile" is the same in the context of the two deliverables: content negotiation and the guidance document.

My guess is that it is not: for the content negotiation part, the "profile" is just an additional constraint to be used when media types are not enough. E.g., I want a metadata record in ISO 19115 (profile) as JSON (media type). Whether the profile denotes a standard, a technical spec, a profile of a standard or of technical spec, etc. this is irrelevant for content negotiation.

But probably I got it totally wrong...

Andrea

----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/


----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

>-----Original Message-----
>From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>Sent: Thursday, May 17, 2018 8:36 AM
>To: Simon.Cox@csiro.au; public-dxwg-wg@w3.org
>Subject: Re: Organizing GitHub issues, projects and milestones for work on
>Profiles
>
>Simon, the problem of using dct:conformsTo here is that it is not
>specific to profiles, so there is no way to know if the object of
>conformsTo is a profile or is something else. If we want content
>negotiation to be able to negotiate on the basis of profiles, then
>having a property which MAY OR MAY NOT have a profile as an object does
>not fulfill that requirement. So profiles may be standards, but not all
>standards are profiles. It's really a very practical and functional need.
>
>kc
>
>On 5/17/18 1:59 AM, Simon.Cox@csiro.au wrote:
>> Hmm. The definition of 'Standard' is elusive.
>> Some folk think that anything short of ISO does not qualify - which is clearly
>silly. There are many 'standards issuing organizations' and their products go
>by different names - standard, specification, recommendation, ...
>>
>> A 'standard' (small 's'?) could be scoped to various organizational structures
>and levels, right down to a single lab or work-group, for example. I think this
>was the sense intended by the axiom
>>
>> prof:Profile rdfs:subClassOf dct:Standard .
>>
>> where dct:Standard is being used to stand for a rather general notion of
>'Specification'.
>>
>> Karen - you appear to have a stricter view, and want to preserve the term
>'standard' for a subset? I wonder if you could explain the boundary with the
>more general concept? Is it something about the issuing body?
>>
>> FWIW I'm of the opinion that since pretty much every 'standard' has
>dependencies on other standards and specifications, the notion of 'profile' is
>not well differentiated from standards or specifications in general. But
>clearly the word 'profile' is in use in the community with some particular
>expectations, so we should attempt to meet them.
>>
>> Simon
>>
>> -----Original Message-----
>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>> Sent: Wednesday, 16 May, 2018 23:58
>> To: public-dxwg-wg@w3.org
>> Subject: Re: Organizing GitHub issues, projects and milestones for work on
>Profiles
>>
>> 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
>>
>
>--
>Karen Coyle
>kcoyle@kcoyle.net http://kcoyle.net

>m: 1-510-435-8234 (Signal)
>skype: kcoylenet/+1-510-984-3600

Received on Thursday, 17 May 2018 07:24:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:43 UTC