Use case: Distinguish query and item access semantics [RDISA]

[rob-metalinkage]

Use case name

Status: new

Identifier:

Creator: rob Atkinson

Deliverable(s):
(DCAT1.1)

Tags

DCAT

Stakeholders

''Mandatory list of stakeholders experiencing the problem. When describing the stakeholder, please be as specific as possible (e.g., data consumer, data producer, data publisher, program, etc.) and avoid using the term user.''

Problem statement

When considering Linked Data applications viewing datasets there are potentially multiple ways to access items. Large datasets in particular may support access to specific items, queries, subsets and optimally packaged downloads of data.

Because the implications for user and agent interaction vary greatly between these modes of access there is a need to distinguish between distributions that package the entire dataset.

Furthermore, access methods delivering queries and subsets may introduce container elements, independently of the dataset itself.

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 same profile 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.

Requirement:
Provide a (single extra level of) finer grainer distinction for AccessURL, consistent with the existing strategy of distinct accessURL and downloadURL.

Existing approaches

VoiD distinguishes between dowload, SPARQLquery and Opensearch - this is overly restrictive but illustrates the conceptual need to distinguish service types.

The concern is echoed here:
"Linked Data Fragments [1] : a uniform view on all Linked Data interfaces
Today’s Web offers three common ways to access Linked Data:

A data dump contains all triples in an entire dataset (example).
A subject page contains triples about a specific subject in a dataset (example).
A SPARQL result contains triples that correspond to a SPARQL CONSTRUCT query (example). "

Links

[1] http://linkeddatafragments.org/concept/

Requirements

[RDISA] Provide a canonical means to distinguish between accessURL usages for list and item endpoints and allow declaration of the supported profiles of both the container mechanism (for list results) and data payload.

Related use cases

Comments

---

[nicholascar]

Discussion about accessURL & downloadURL and a possible super property of both with qualifications for specialisations here: #124

[nicholascar]

(Jaroslav_Pullmann): The issue may relate to (distinguishing) a packaged Distribution: https://www.w3.org/TR/dcat-ucr/#ID1

[smrgeoinfo]

Discussion about accessURL & downloadURL and a possible super property of both with qualifications for specialisations here: #124

Yes-- the solution for that issue should also solve this one.

[agbeltran]

Just a note that this use case has not been added to the UCR document

[andrea-perego]

Discussion about accessURL & downloadURL and a possible super property of both with qualifications for specialisations here: #124

Yes-- the solution for that issue should also solve this one.

As #124 has been addressed, I propose we close this issue.

[andrea-perego]

Discussion about accessURL & downloadURL and a possible super property of both with qualifications for specialisations here: #124

Yes-- the solution for that issue should also solve this one.

As #124 has been addressed, I propose we close this issue.

No objections raised. Closing this issue.