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

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

Received on Tuesday, 12 December 2017 20:25:25 UTC