- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 17 May 2018 08:35:59 +0200
- To: Simon.Cox@csiro.au, public-dxwg-wg@w3.org
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 06:36:34 UTC