W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2018

RE: Definitions page for Profiles

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Wed, 10 Jan 2018 07:44:41 +0000
To: Antoine Isaac <aisaac@few.vu.nl>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <e414d3871098469dac1118c2a681c452@dnb.de>
On Wednesday, January 10, 2018 12:13 AM, Antoine Isaac [mailto:aisaac@few.vu.nl] wrote:

[...]

> But well, as discussed today, maybe I should wait and see if the work on our various
> specs brings some clearer motivation for drawing such a line. Maybe it will. But if it
> does I'm fairly sure that the work on content negotiation will not draw such line: i.e.
> DCAT will be a 'data profile' worth being included in content negotiation, whether we
> think it is itself an AP or not.

Yes, the conneg will really only match on IRI (and perhaps do some magic on profiles being composed from other profiles). What kind of artefact that IRI identifies is more or less out of scope. I'd argue that there shall be a SHOULD requirement that profile IRIs dereference to a human- and/or machine-readable documentation, but it will work without that, too.

Best,

Lars
 
> On 09/01/18 22:40, mail@makxdekkers.com wrote:
> > I think there is a good reason to keep the definition of properties and classes (in a
> namespace) separate from definitions of constraints (in profiles). Namespaces and
> profiles have different maintenance requirements.
> >
> > I have been using the split in all my work and I have never encountered a problem;
> if necessary, you just create a namespace for properties and classes that you need,
> and then you define constraints on those new terms in a profile which lives at a
> different URI.
> >
> > What would be the argument for mixing these different things into a single schema?
> >
> > Makx.
> >
> >
> > -----Original Message-----
> > From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> > Sent: 09 January 2018 22:02
> > To: public-dxwg-wg@w3.org
> > Subject: Re: Definitions page for Profiles
> >
> > Antoine, I don't know exactly why that was the decision, although there is, in my
> mind, a practical question of what properties are needed to define new terms, and if
> those fit with the properties of a profile.
> > Possibly there are also issues of IRI naming and discovery.
> >
> > kc
> >
> > On 1/9/18 12:42 PM, Antoine Isaac wrote:
> >> Hi Karen,
> >>
> >> You're probably going to hate me for this reaction, especially
> >> considering the time we've worked together on APs in the DC community...
> >> But is there a very strong reason to say that something wouldn't be a
> >> profile because it originates classes and properties?
> >> To me what was core was the notion of re-using other
> >> vocabularies/model (it would be much harder to define as a profile
> >> something that *only* originates classes and properties), but it
> >> wasn't obvious that it would forbid minting own classes and properties when
> appropriate.
> >> So if it makes things easier and this rule of thumb can be softened
> >> (if it does exist), perhaps we could propose it to the DC community?
> >>
> >> Antoine
> >>
> >> On 18/12/17 15:31, Karen Coyle wrote:
> >>> Andrea, in answer to #2, by the Dublin Core definition, DCAT itself
> >>> would not be a profile because it originates classes and properties.
> >>> DC profiles reuse but do not create vocabulary elements. A DC profile
> >>> is always based on vocabularies defined (preferably in a standard
> >>> way) elsewhere.
> >>>
> >>> That said, presumably you could create a DCAT profile that is exactly
> >>> all of the classes and properties that are included in DCAT. If
> >>> profiles include information such as cardinality, value pick lists,
> >>> etc., then such a profile would provide information not included in
> >>> the DCAT ontology.
> >>>
> >>> kc
> >>>
> >>>
> >>> On 12/18/17 5:05 AM, andrea.perego@ec.europa.eu wrote:
> >>>> Dear Karen, dear Ruben,
> >>>>
> >>>> Thanks for initiating this page.
> >>>>
> >>>> A couple of comments / questions:
> >>>>
> >>>> 1. I think it may be worth including an explicit reference to the
> >>>> definition of "profile" from RFC 6906 ("The 'profile' Link Relation
> >>>> Type") [1]. @Ruben, if I'm not mistaken your definitions are
> >>>> partially based on it.
> >>>>
> >>>> 2. Looking at the wiki page, it is unclear whether DCAT itself (and
> >>>> any metadata schema, vocabulary, etc.) is considered or not a "profile".
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Andrea
> >>>>
> >>>> ----
> >>>> [1] https://tools.ietf.org/html/rfc6906

> >>>>
> >>>> ----
> >>>> 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: Sunday, December 17, 2017 5:11 PM
> >>>>> To: public-dxwg-wg@w3.org
> >>>>> Subject: Definitions page for Profiles
> >>>>>
> >>>>> Ruben and I have done the first set of definitions on the Profiles
> >>>>> Context page [1]. You should add your own definitions and also
> >>>>> comment on those that are there. This is a brainstorming exercise
> >>>>> so please toss out your thoughts, respond to definitions and
> >>>>> comments, and contribute to this.
> >>>>>
> >>>>> kc
> >>>>> [1]
> >>>>> https://www.w3.org/2017/dxwg/wiki/ProfileContext#Discussion_of_Defi

> >>>>> nitions
> >>>>>
> >>>>> --
> >>>>> 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 Wednesday, 10 January 2018 07:45:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:56 UTC