Re: Additional UseCase / Requirements

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