- 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>
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