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: Thu, 17 May 2018 10:56:20 +0200
To: Simon.Cox@csiro.au, andrea.perego@ec.europa.eu, public-dxwg-wg@w3.org
Message-ID: <1e15999e-2e39-f960-b9c3-2fcb013ff986@kcoyle.net>
I suspect this may be true for content negotiation, but presumably there
are other functions - such as identifying or locating a profile that
informs you about a certain dataset. A dataset may conform to a number
of standards and ALSO have a related profile that defines the metadata
schema being used.

I can give examples from the library world, but I'm not sure how much
they'll resonate with the group. I can have a BIBFRAME profile [1] that
is a selection of terms in the BIBFRAME namespace and that conforms to
the library cataloging standard, RDA. [2] Those are two very different
things and it can be important to know both. In addition, you could
specify that the data conforms to Unicode utf-8 encoding.

In another example, my data may use a subset of the schema.org ontology
that I have specified as a profile and the rules Descriptive Cataloging
of Rare Materials (Books) (DCRM(B), 2007).

In general, I want to be able to indicate which is the profile and which
are the conforming standards.

kc
[1] http://bibfra.me/
[2] http://www.rdaregistry.info/

On 5/17/18 10:19 AM, Simon.Cox@csiro.au wrote:
>> 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.
> 
> Yes. It might also be "schema" or "view". 
> From the point of view of conformance, these probably serve the same function. 
> 
> -----Original Message-----
> From: andrea.perego@ec.europa.eu [mailto:andrea.perego@ec.europa.eu] 
> Sent: Thursday, 17 May, 2018 17:24
> To: kcoyle@kcoyle.net; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-dxwg-wg@w3.org
> Subject: RE: Organizing GitHub issues, projects and milestones for work on Profiles
> 
> 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
> 

-- 
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 08:56:53 UTC

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