Re: Conneg definition was: Re: Start of profiles analysis page - 2nd reply

I think we can "eat our own dog food" and "have our cake and eat it too" -
with conneg.  IMHO Profiles should be available as HTML and canonical RDF
definitions, (and an arbitrary set of alternative representations) - the
definition should use inheritance (for semantic accuracy of how profiles
relate to each other), but also offer a canonical link to a flattened view,
which can also be accessed via profile negotiation.  The HTML view should
be perhaps be the flattened view, with every constraint linked back to the
parent profile that defines it.

This may sound like a burden, but its quite a trivial burden on
infrastructure compared to the burden on end users trying to work out what
is the same and different in a forest of PDF documents of overlapping
profiles descriptions. (whilst we want to make publication easy, make end
use impossible is a poor compromise)

This does suggest we want a canonical RDF model for a flattened profile
with embedded references to the parents for each constraint. I have to have
such a thing anyway for the real-world set of profiles I have to handle in
the OGC context, and happy to put it forward as an extra deliverable. As i
mentioned on the call, the hardest part will be choosing or abstracting
from a model of the things being profiled. Maybe we define an abstract
ObjectProperty for the profiled entity, then allow it to be sub-typed to
specify what type of entitiy is being profiled.

Rob



On Wed, 13 Dec 2017 at 07:24 Annette Greiner <amgreiner@lbl.gov> wrote:

> The analogy from software is what worries me most about inheritance in
> profiles. If we make it behave like OO software, we run into the issue
> of getting hold of the correct versions of the inherited
> libraries/profiles. Any developer who has written complex software knows
> the pain of dealing with dependencies. If we allow inheritance by
> reference alone, we force dependencies into the mix. Interoperability
> would, I think, be much easier if each profile stood on its own merits
> without requiring following up a list of dependencies (either in code or
> manually). Unless there is a clear case where inheritance by reference
> is needed, I would vote against that.
>
> -Annette
>
>
> On 12/10/17 5:34 AM, Svensson, Lars wrote:
> > . . . I'd say that a profile should indicate if it extends (=reuses
> > the basic structure and constraints of) another AP. We could even go
> > as far as saying that the extending profile only lists constraints
> > that were added or modified and that for all other purposes we should
> > refer to the profile it extends (similar to a class in OO programming
> > that extends another class and only specifies what it has added while
> > everything else is inherited from the superclass).
> > Best,
> >
> > Lars
> >
> >> -----Original Message-----
> >> From: Annette Greiner [mailto:amgreiner@lbl.gov]
> >> Sent: 08 December 2017 20:42
> >> To: public-dxwg-wg@w3.org
> >> Subject: Re: Conneg definition was: Re: Start of profiles analysis page
> - 2nd reply
> >>
> >> Oh, maybe I misunderstood. Is the DCAT-AP for Europe a true parent of
> these other
> >> DCAT-AP-Xs? I was thinking of the (nonexistent) DCAT-AP as a general
> parent of
> >> DCAT-AP for Europe as well the others. That is what I was thinking
> doesn't exist. The
> >> namespacing here is very confusing.
> >>
> >>
> >> On 12/8/17 8:12 AM, Karen Coyle wrote:
> >>> I'm not sure what you mean by "flat". I'd say that DCAT-AP is an AP,
> >>> but since there's no particular "standard" or "guidance" for APs, it
> >>> is self-defined in terms of its mode of expression of the content of
> >>> the AP. Does that make sense?
> >>>
> >>> kc
> >>>
> >>> On 12/8/17 7:59 AM, Annette Greiner wrote:
> >>>> Except that there is no such thing as a profile called DCAT-AP,
> right? The space is
> >> still flat.
> >>>> -Annette
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>> On Dec 8, 2017, at 3:42 AM, <Peter.Winstanley@gov.scot>
> >> <Peter.Winstanley@gov.scot> wrote:
> >>>>> Hi Karen - the data.  And yes, inheritance too.
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> >>>>> Sent: 08 December 2017 11:21
> >>>>> To: public-dxwg-wg@w3.org
> >>>>> Subject: Re: Conneg definition was: Re: Start of profiles analysis
> >>>>> page - 2nd reply
> >>>>>
> >>>>> Peter, are you referring to the data that is coded using that AP, or
> >>>>> the AP itself? As far as I know, if you want the data coded in
> >>>>> DCAT-AP but not DCAT-AP-IT the site providing the data would need to
> >>>>> be able to create the DCAT-AP-only dataset. If they cannot, then you
> >>>>> could accept DCAT-AP-IT and perform the limiting to DCAT-AP at your
> >>>>> end. (This also brings up the notion of cascading/inheriting in APs,
> >>>>> another sticky topic on our plate.)
> >>>>>
> >>>>> kc
> >>>>>
> >>>>>> On 12/8/17 2:52 AM, Peter.Winstanley@gov.scot wrote:
> >>>>>> So in a DCAT-AP context we are getting national catalogues with
> refinements on
> >> the core DCAT-AP.  AFAIK there is a DCAT-AP-IT for italy, and a
> DCAT-AP-SK for
> >> Slovakia.  The convention seems to be developing in this way using a
> 2char country
> >> code.
> >>>>>> If I want to merge then perhaps I just want the DCAT-AP version
> without any
> >> country-specific additions.
> >>>>>> Would this be an appropriate and testable use case for this?
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> >>>>>> Sent: 08 December 2017 10:38
> >>>>>> To: public-dxwg-wg@w3.org
> >>>>>> Subject: Conneg definition was: Re: Start of profiles analysis page
> >>>>>> - 2nd reply
> >>>>>>
> >>>>>> Annette, thanks for the reality check. And as Ruben says, the main
> >>>>>> aim is to access data that matches one or more application profiles.
> >>>>>>
> >>>>>>> On 12/8/17 1:24 AM, Ruben Verborgh wrote:
> >>>>>>> Hi Annette,
> >>>>>>>
> >>>>>>>> In my mind, the conneg bit that's needed is about adding the
> ability to
> >> negotiate not the profile itself but the distribution (of a dataset)
> that supports a
> >> preferred profile.
> >>>>>> The only requirement seems to be:
> >>>>>>
> >>>>>> 6.8.3 Profile negotiation
> >>>>>> Create a way to negotiate choice of profile between clients and
> >>>>>> servers
> >>>>>>
> >>>>>> Perhaps that needs to be more specific so that it is clearly about
> >>>>>> choosing data that is consistent with a given application profile.
> >>>>>>
> >>>>>> kc
> >>>>>>
> >>>>>>> The second is our main aim,
> >>>>>>> but conneg clearly also makes sense for the profile itself if that
> >>>>>>> is available in multiple representations.
> >>>>>>>
> >>>>>>>> Content negotiation already has the capability to handle the case
> of
> >> requesting a copy of astrodcat itself as astrodcat.rdf vs astrodcat.xml
> vs
> >> astrodcat.json.
> >>>>>>> Indeed, it's this mechanism I propose to reuse (but no need to
> >>>>>>> mandate that).
> >>>>>>>
> >>>>>>> Ruben
> >>>>>>>
> >>>>> --
> >>>>> Karen Coyle
> >>>>> kcoyle@kcoyle.net http://kcoyle.net
> >>>>> m: 1-510-435-8234 (Signal)
> >>>>> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> >>>>>
> >>>>>
> >>>>> ____________________________________________________________________
> >>>>> __ This email has been scanned by the Symantec Email Security.cloud
> >>>>> service.
> >>>>> For more information please visit http://www.symanteccloud.com
> >>>>> ____________________________________________________________________
> >>>>> __
> >>>>>
> >>>>> ********************************************************************
> >>>>> ***********************************************************
> >>>>> This email has been received from an external party and has been
> swept for the
> >> presence of computer viruses.
> >>>>> ********************************************************************
> >>>>> ***********************************************************
> >>>>>
> >>>>>
> >>>>> ********************************************************************
> >>>>> ** This e-mail (and any files or other attachments transmitted with
> >>>>> it) is intended solely for the attention of the addressee(s).
> Unauthorised use,
> >> disclosure, storage, copying or distribution of any part of this e-mail
> is not permitted.
> >> If you are not the intended recipient please destroy the email, remove
> any copies from
> >> your system and inform the sender immediately by return.
> >>>>> Communications with the Scottish Government may be monitored or
> recorded in
> >> order to secure the effective operation of the system and for other
> lawful purposes.
> >> The views or opinions contained within this e-mail may not necessarily
> reflect those of
> >> the Scottish Government.
> >>>>>
> >>>>> Tha am post-d seo (agus faidhle neo ceanglan còmhla ris) dhan neach
> neo luchd-
> >> ainmichte a-mhàin. Chan eil e ceadaichte a chleachdadh ann an dòigh sam
> bith, a’ toirt
> >> a-steach còraichean, foillseachadh neo sgaoileadh, gun chead. Ma ’s e
> is gun d’fhuair
> >> sibh seo gun fhiosd’, bu choir cur às dhan phost-d agus lethbhreac sam
> bith air an t-
> >> siostam agaibh agus fios a leigeil chun neach a sgaoil am post-d gun
> dàil.
> >>>>> Dh’fhaodadh gum bi teachdaireachd sam bith bho Riaghaltas na h-Alba
> air a
> >> chlàradh neo air a sgrùdadh airson dearbhadh gu bheil an siostam ag
> obair gu h-
> >> èifeachdach neo airson adhbhar laghail eile. Dh’fhaodadh nach  eil
> beachdan anns a’
> >> phost-d seo co-ionann ri beachdan Riaghaltas na h-Alba.
> >>>>> ********************************************************************
> >>>>> **
> >>>>>
> >>>>>
> >> --
> >> Annette Greiner
> >> NERSC Data and Analytics Services
> >> Lawrence Berkeley National Laboratory
> >>
> >>
>
> --
> Annette Greiner
> NERSC Data and Analytics Services
> Lawrence Berkeley National Laboratory
>
>
>