- 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