Scope notes for URL properties

[smrgeoinfo]

In spite of the discussion in #249, #655, #740, I think the scope notes in the current editor draft for accessURL, downloadURL and endpointURL are confusing, and the Range value 'rdfs:Resource' opens to the possibility for all kinds of incompatible/interoperable implementations that are consistent with the spec.

In all the implementation examples, the value provided for these ...URL properties is an HTTP URI (or IRI) reference by identifier (i.e. an IRI enclosed in <>). For accessURL the reference is always to a web page; for downloadURL the reference is always to a file, for endpointURL the reference is always to a web location that will respond to properly constructed service requests. Are there any other rdfs:Resources that could serve as valid values for these?

Is the intention to allow an in-line blank node for any rdfs:Resource, or a reference identifier for anything?

accessURL scope note states 'SHOULD be used for the URL of a service or location that can provide access to this distribution, typically through a Web form, query or API call.' if the dataset is accessed via API dcat:accessService/dcat.endpointURL be used? If the accessURL is a complete service URL that can be invoked to get the resource distribution in a response (client need know nothing about the service API or query syntax), then the resource that is the object of the property is the file that is returned, and downloadURL is more applicable.

Suggested language:
6.7.9 accessURL An IRI reference to a web location that a human interacts with to obtain the resource distribution.
Usage note: AccessURL SHOULD be used when the distribution can only be obtained by interacting with a landing page or web form.

6.7.11 downloadURL An IRI reference that can be dereferenced to obtain the distribution object directly.
Usage note: SHOULD be used when a web-dereferencable identifier for the distribution object is available.

6.8.1 endpointURL. Definition: An IRI reference to a web location that will respond to properly constructed service requests to provide access to the resource distribution.
Usage note: Associated endpoint description and distribution type properties provide additional information necessary for clients to obtain the desired distribution through service operations.

[dr-shorthair]

@smrgeoinfo you might have overlooked dcat:landingPage.

[smrgeoinfo]

I did indeed. foaf:Document is the Range for dcat:landingPage and for foaf:homePage, which is a property of dcat:Catalog. In practice (the dcat examples and foaf spec examples), properties that have Range foaf:Document get populated with http URI references that are urls to get the document, which might be a web page, or some other file that gets returned to the requesting client.

Instantiating the class in an instance document allows inclusion of some metadata about the document, dct metadata properties in the dcat examples. The foaf:Document instances in the examples are the target of a dct:relation, which has no range specified.

foaf:Document as the Range for dcat:landingPage seems to work well enough. I suppose if accessURL were reanamed 'accessPage', foaf:Document would be a more precise range, but not a big enough difference to change things at this point IMO.

[dr-shorthair]

Indeed we are being caught up with loose semantics inherited from FOAF ...
This property was introduced in DCAT-2014 so there is a backwards-compatibility concern.

The intention is for this property to hold a URL which links to a web-page, which is a kind of document. Perhaps we just need to tighten up the usage notes to clarify this?

[smrgeoinfo]

@dr-shorthair Do you think the suggested language in the original issue text (above) will work?

[dr-shorthair]

The text for dcat:Distribution/dcat:downloadURL and dcat:DataService/dcat:endpointURL are OK, but I don't think you got it quite right for dcat:Distribution/dcat:accessURL which needs to fit together with the explanation of dcat:Resource/dcat:landingPage.

6.7.9 accessURL An IRI reference to a web location that a human interacts with to obtain the resource distribution.

not just humans

Usage note: AccessURL SHOULD be used when the distribution can only be obtained by interacting with a landing page or web form.

'only' is definitely not the case here. And typicaly the accessURL will be an endpoint, not a landing page - as clearly indicated by the property-chain dcat:accessService/dcat:endpointURL. In fact a 'landing page' is not usually expected for a distribution, it is more often associated to the dataset, which is why it is recommended for the latter but not mentioned in the context of the former. The endpoint will often itself have a landing page, but that is incidental.

I think I'd suggest

6.7.9 accessURL An IRI reference to a resource that a client interacts with to obtain the resource distribution.
Usage note: AccessURL SHOULD be used for the URL of a service that can provide access to this distribution, typically through query or API call. AccessURL MAY be used when the distribution can be obtained by interacting with a landing page or web form.

As for the matter of whether the range rdfs:Resource is too open: this is intentional. We don't want to unnecessarily limit use of these predicates in other contexts. In general we have erred in the side of textual guidance rather than strict axiomatization.

[davebrowning]

As we are very near the deadline for DCAT 2 (possibly at it...), with a lot of review already done I'd like to propose that this discussion is held over for later work, if that's okay?

[davebrowning]

@smrgeoinfo - Stephen, we've run out of time to try to factor these improvements into this version and still get everything through the process, so we're prosing leaving them on file to get factored into future work as and when that can happen - perhaps as early as next year, in a more incremental approach, though that's not guaranteed yet.

Hope this is okay - thanks for your time & effort - you have helped us improve the deliverable quite a bit

[smrgeoinfo]

No problem. People can refine guidance in local profile instructions to work in their community.