Re: Additional UseCase / Requirements

Rob, we can put this on next week's plenary agenda if you feel ready to
discuss and vote on it. It will need one or more stated requirements;
those could come out of the plenary discussion if you think that is best.

kc

On 3/1/18 4:19 AM, Rob Atkinson wrote:
> 
> Good question - i am thinking mainly about the case where the container
> and the contents need to be described (a list) and making sure we can
> handle this - and also the need to tell people that a link is safe to
> follow (an item) - or a commitment to download an entire data set and
> find the item. This initial distinction has quite of lot of extra
> utility in that regard and can handle quite general cases in the spirit
> of dcat.
> 
> i..e certainly not as specific as GraphQL -  i think to go to a finer
> grained distinction we would need another use case or more evidence of
> need and practice. 
> 
> So if the library desk has a URI identifier and can deliver a result set
> represented with an identified profile of some spec, and packaged in an
> identifiable container - then why not?
> 
> Rob
> 
> 
> 
> On Thu, 1 Mar 2018 at 22:43 pedro winstley
> <pedro.win.stan@googlemail.com <mailto:pedro.win.stan@googlemail.com>>
> wrote:
> 
>     Hi Rob
> 
>     In your item #2 about the nature of the deliverable/s from the
>     'endpoint', what assumptions are being made about the nature (e.g.
>     transport protocol) for this 'endpoint'.  I mean, could it be a
>     library desk, for example; or an xmlrpc call?  Or are we just
>     imagining HTTP endpoints with REST/HATEOAS , or perhaps GraphQL
>     endpoints?
> 
>     Peter
> 
>     On 28 February 2018 at 22:10, Rob Atkinson <rob@metalinkage.com.au
>     <mailto:rob@metalinkage.com.au>> wrote:
> 
>         When considering Linked Data applications of dataset
>         descriptions, and content negotiation by profile, there is a
>         need to distinguish between distributions that package the
>         entire dataset - and hence may have a "container" structure, and
>         service endpoints that deliver a specific object.
> 
>         So if we had a metadata catalog that supported a query service
>         that returned a set of DCAT records (using say the BotDCAT-AP
>         profile), and also an api that delivered a specific record using
>         this:
> 
>         1) we would need to be able to specify the query service support
>         the BotDCAT-AP profile and MyDCATCatalogSearchFunction profile
>         (that specifies how the container structure is implemented?)
> 
> 
>         2) we need to distinguish between enpoints that
>         a) deliver a single item
>         b) deliver a list based on some filter/criteria
>         c) deliver the entire dataset
> 
>         case c) is  covered by dcat:downloadURL but dcat:accessURL is
>         too general to distinguish between the others. we need  one of:
>         i.) canonical subclasses  of accessURL or item and list endpoints
>         ii.) a type property (dct:type?) for the distribution with
>         canonical values for list and endpoint cases
>         iii) a property  e.g. dcat:containerProfile to indicate that
>         data conforming to a domain profile will be wrapped in a
>         container conforming to an access method profile.
> 
>         Note - I will be able to provide an implementation of whatever
>         method is chosen - currently having to create my own vocab to
>         annotate links these ways - so trivially easy to update to DCAT
>         support for these notions.
> 
>         Should I also formally submit this as a comment as feedback to
>         the UCR - or is this sufficient to process it as such. 
>          
>         Apropos of this, I have a little profiles vocabulary in
>         preparation I will post during the week that will allow short
>         tokens to be association with profiles for use in access
>         endpoints and profile negotiation,  whether this vocabulary is a
>         standandalone and subclasses dcat:accessURL or whether all or
>         part could be rolled into dcat is an open question. It would
>         provide a canonical means for dcat to specify profile
>         conformance, but adds a little structure. 
> 
>         Maybe using the modular approach discussed I should join the
>         DCAT sub group and propose it, with a fall back of a separate
>         namespace?
> 
>         Rob Atkinson
> 
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 1 March 2018 15:51:12 UTC