Re: Additional UseCase / Requirements

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