- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Tue, 15 May 2018 17:37:21 +1000
- To: "Svensson, Lars" <L.Svensson@dnb.de>
- Cc: "kcoyle@kcoyle.net" <kcoyle@kcoyle.net>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
- Message-ID: <CACfF9LyhPV8_m17c9GtiHnPJknthf_MNwi5gyjppgF3VzWfOSg@mail.gmail.com>
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> wrote:
> On Friday, May 11, 2018 9:26 AM, Karen Coyle [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://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> > Gks5dDa8n2B5IN6rWa3kRpo/
> > >
> > > [7] https://www.w3.org/2017/dxwg/track/actions/109
> > > [8] https://github.com/w3c/dxwg/projects/2
> > > [9] https://github.com/w3c/dxwg/milestone/9,
> > > https://github.com/w3c/dxwg/milestone/10,
> > > 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>> 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>]
> > >> Sent: Thursday, 26 April, 2018 01:55
> > >> To: 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>
> > >> >
> > >> > [2] 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>
> > >> >
> > >> > [4] 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/>
> > >> >
> > >> >
> > >> >
> > >> > *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>>
> > >> >
> > >> >
> > >
> > >
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > m: 1-510-435-8234 (Signal)
> > skype: kcoylenet/+1-510-984-3600
>
>
Received on Tuesday, 15 May 2018 07:38:07 UTC