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