W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > July 2019

Aw: Re: Trying to articulate our various "profiles"

From: <lars.svensson@web.de>
Date: Wed, 3 Jul 2019 16:39:24 +0200
Message-ID: <trinity-44b7e8c6-5749-4e8e-b76e-f8ed0cbcfff8-1562164764060@3c-app-webde-bs22>
To: kcoyle@kcoyle.net
Cc: public-dxwg-wg@w3.org
I don't think that there is one and only one "intent of conneg in terms of what types of "things" it wishes to negotiate on". Technically you can negotiate on anything (the IETF spec only compares URIs).

*My* personal use case is negotiation on "application profile" (i. e. give me this person description in as text/turtle using the foaf profile and if you cannot provide foaf use schema instead).

I believe, however, that at least Rob has use cases that go beyond that.

Best,

Lars

> Gesendet: Mittwoch, 03. Juli 2019 um 15:59 Uhr
> Von: "Karen Coyle" <kcoyle@kcoyle.net>
> An: public-dxwg-wg@w3.org
> Betreff: Re: Trying to articulate our various "profiles"
>
> I would find it helpful to learn the *intent* of conneg in terms of what
> types of "things" it wishes to negotiate on. Since it is hard to
> elaborate, a set of examples that cover as many cases as possible would
> be good.
>
> I know that we rejected "application profile" early on, but it is quite
> clear that the term "profile" alone has meanings beyond our purpose.
>
> kc
>
> On 7/2/19 7:28 PM, Cox, Simon (L&W, Clayton) wrote:
> > Indeed. I wish conneg had used 'schema' instead of profile.
> >
> > -----Original Message-----
> > From: Antoine Isaac [mailto:aisaac@few.vu.nl]
> > Sent: Wednesday, 3 July, 2019 01:13
> > To: public-dxwg-wg@w3.org
> > Subject: Re: Trying to articulate our various "profiles"
> >
> > I agree that the market can be confused, but this is already the case and we won't be able to change it.
> >
> > I.e. plenty people use "data profiling" to refer to identify the "shape" of the data (i.e. the elements it includes) [1] JSON-LD has also profiles.
> > In both cases, the profile doesn't really need to be a profile of anything. Especially the first.
> >
> > Btw JSON-LD tries to limit the mayhem by using a term that's not (yet) too overloaded, "form": https://w3c.github.io/json-ld-syntax/#forms-of-json-ld
> > Maybe they've adopted this after our F2F discussion in Lyon, where we managed to untangle the notions of profiles used by both groups.
> >
> > Note that I'm not trying to use the word profile at any cost for things that are not based on other things. It was just a handle that I needed, and honestly I couldn't find any other term than this "data profile". And then my trying to unify the two notions at hand (DCAT#2/APs and DCAT#1/CONNEG at [3]) meant that yes, in the end the nuance was lost.
> >
> > @Annette @Simon would it actually make it easier if we tried to use two definitions (subsumed by another), one being specific for when there's profiling of an existing specification (DCAT#2/APs) and one when it's optional (DCAT#1/CONNEG)?
> >
> > Antoine
> >
> > [1] https://en.wikipedia.org/wiki/Data_profiling
> > [2] https://w3c.github.io/json-ld-syntax/#application-ld-json
> > [3] https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0106.html
> >
> > On 26/06/2019 05:31, Cox, Simon (L&W, Clayton) wrote:
> >> I tend to agree.
> >>
> >> 'Specification' is the general case.
> >>
> >> While all specifications have dependencies, 'Profiles' are the subset where an explicit dependency(s) is(are) somehow essential to their use.
> >>
> >> The patterns are clear, and the same model (e.g. the Profiles vocabulary) could likely be used to describe all cases. But use of the term 'Profile' for the general case appears to be confusing to the market.
> >>
> >> Simon
> >>
> >> -----Original Message-----
> >> From: Annette Greiner [mailto:amgreiner@lbl.gov]
> >> Sent: Wednesday, 26 June, 2019 06:11
> >> To: public-dxwg-wg@w3.org
> >> Subject: Re: Trying to articulate our various "profiles"
> >>
> >> Please accept my regrets. I'm going to have to miss today's meeting, but I wanted to weigh in on this discussion.
> >>
> >> As I see it, the real problem we have is that we have sometimes considered profiles to include specifications like DCAT and sometimes not. That difference suggest to me that we haven't got a consistent term and are therefore developing inconsistent recommendations. It means we need to rethink our definitions.
> >>
> >> We could remedy the issue by enlarging all definitions of profiles to
> >> include specifications, or by defining profiles more narrowly and
> >> referring to the entities that can be negotiated or "conformedTo" with
> >> a term that applies to both profiles and specifications. ("metamodel
> >> negotiation"?) I find attempts to do the former odd and forced.
> >>
> >> I'm uncomfortable defining profiles such that they include formal specifications. I think that breaks with existing understanding in a way that is confusing. I understand that a specification can be seen as a profile of itself, sort of the trivial case of a profile that is based on the standard without adding any constraints. But the whole purpose of using profiles has always been to codify a customized version of a formal standard. I like the idea of allowing profiles that are based on multiple standards, and I agree that there needn't be a single base standard, but I think an entirely new specification that isn't based substantially on anything previous is not a profile. If it is, then all specifications are profiles, and we've defined nothing new.
> >>
> >> Profiling is about acknowledging a reuse. The threshold at which that acknowledgment is called for would be hard to define, but it seems to me that it is up to the creator of the spec or profile what level of acknowledgment they want to advertise. For example, I don't think that DCAT becomes a profile of vCard by including vCard elements. And I don't think we would want to advertise it as such, because we don't have the goal of creating a version of vCard that suits the needs of a specific community. I think it comes down to the intent.
> >>
> >> -Annette
> >>
> >> On 6/25/19 10:43 AM, Karen Coyle wrote:
> >>> Antoine, this is excellent and thank you for this analysis.
> >>>
> >>> So the full definition would be:
> >>>
> >>> "A named set of constraints which can be based on one or more
> >>> identified base specifications, including the identification of any
> >>> implementing subclasses of datatypes, semantic interpretations,
> >>> vocabularies, options and parameters of those base specifications
> >>> necessary to accomplish a particular function."
> >>>
> >>> I wouldn't mind reducing the list of possible elements there, if we can.
> >>> It's kind of a mouthful. Perhaps we can revisit those when we've gone
> >>> a bit further into the discussion.
> >>>
> >>> kc
> >>>
> >>> On 6/25/19 9:43 AM, Antoine Isaac wrote:
> >>>> "A named set of constraints, which can be based on one or more other
> >>>> identified specifications, [etc]"
> >>
> >> --
> >> Annette Greiner
> >> NERSC Data and Analytics Services
> >> Lawrence Berkeley National Laboratory
> >>
> >>
> >
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> skype: kcoylenet
>
>
Received on Wednesday, 3 July 2019 14:40:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:54 UTC