Range axiom is redundant, given that it is rdf:type owl:ObjectProperty

DataAccessURL is a very general - does it need subProperties for Query(List) and Item styles of access.

Perhaps a better thing to do than require further properties/constrains on accessURL would be to allow for the qualification of a more generic URL property for things in DCAT and then have as two specialisations equivalents to dcat:downloadURL & dcat:accessURL. This would allow for both backwards compatibility and also for further subclassing/vocabularisation to cater for more cases.

ISO19115-1 has a DS_OnlineFuctionCode which can be used to categorise links for a dataset, for example a download, search or fileAccess link. We could include/go beyond those various categories by including/extending those terms in a URL usage type vocab.

The Geoscience Australia profile of the ISO19115-1 standard (http://pid.geoscience.gov.au/def/schema/ga/ISO19115-1-2014) extends the normal code list to include a provenanceQueryService type link which is to be interpreted as a link to a PROV query service, as per PROV-AQ:query service relevant to the dataset.

:DatasetX dcat:distribution [
    dcat2:qualifiedURI [
        a dcat2:QualifiedURI ;
        prov:role xxx:DownloadURI ;
        dcat2:hasURIValue <http://something.com/getdata/1234> ;
    ] ;
    dcat2:qualifiedURI [
        a dcat2:QualifiedURI ;
        prov:role xxx:ProvenanceQueryService;
        dcat2:hasURIValue <http://something.com/queryservice?dataset=1234> ;
    ]
]

This is a fair bit more structure imposed on dcat usage, for more flexibility.

It is not incompatible with also specialising dataAccessURL for these key cases. I think you would need to model the equivalence in a way they entail each other.

the role can be best qualified by pointing to an actionable specification (i.e. a profile) rather than another external vocabulary, this way we get basic type information from the subclass and a more descriptive extension mechanism, and no need to maintain a separate classification vocabulary. People can subclass accessURL and force entailment to provide finer grained (e.g. SPARQL endpoint - which can be described by void:sparqlEndpoint)

Maintaining an extensible vocabulary is problematic - some superclasses is relatively easy for a limited lifespan WG

@rob-metalinkage are you saying better something like:

:DatasetX dcat:distribution [
    dcat:qualifiedURI [
        a dcat2:DownloadURI ;
        dcat2:hasURIValue <http://something.com/getdata/1234> ;
    ] ;
    dcat:qualifiedURI [
        a dcat2:ProvenanceQueryService;
        dcat2:hasURIValue <http://something.com/queryservice?dataset=1234> ;
    ]
]

where the classes DownloadURI & ProvenanceQueryService are within a limited set of subclasses of a generic URL class that is included in the DCAT2 ontology, rather than using roles out to another vocab.

Or, do you mean to do more than just include a range of subclasses like with profiles of a generic URL class?

dcat:downloadURL already exists

dcat:queryURL and dcat:getItemURL as subproperties of dcat:accessURL

of course, these things need to be qualified as to the details - but this is already in scope of #56 - so really just joining the dots between these two issues - but referencing a missing use case I think to be able to identify what distributions support hyperlink access for elements in a dataset.

I agree with @nicholascar that we could think of creating a new property (e.g. dcat:distributionURL) that is the super-property of dcat:accessURL and dcat:downloadURL and additional sub-properties for other types of access and reuse.

The proposed model for adding Services to DCAT has a link from Distribution to DataDistributionService.
https://github.com/w3c/dxwg/wiki/Cataloguing-data-services#chosen-solution

This link has essentially the same semantics as dcat:accessURL, but the proposed RDF has

1. a global range constraint
2. a better name dcat:accessService.

I suggest

• add dcat:accessService to DCAT-rev
• deprecate dcat:accessURL and move it to the DCAT2014 graph, and also include an axiomdcat:accessService rdfs:subPropertyOf dcat:accessURL in order to retain full compatibility with existing services that have used this property

Please allow me to disagree strongly with the proposal to deprecate dcat:accessURL for the simple reason that this is one of the most used properties of DCAT. Moreover, if dcat:accessService has essentially the same semantics as dcat:accessURL, I don't see any need at all to confuse implementers by changing the URI.

Thanks @makxdekkers

Provided we include accessURL in the DCAT-2014 profile, then no harm is done to any existing implementations, which can continue to use DCAT-2014. But looking to the future rather than the past, dcat:accessService will be much less confusing to implementers than dcat:accessURL.

<soapbox>
IMHO calling any object-property aaaURL is missing the point. A URL is a designator, not a resource. An object-property links between resources, not their identifiers. When I see a property named aaaURL then I expect the value to be a literal of type xsd:anyURI - i.e. a string which is a URI. So while I acknowledge that the textual definition of accessURL is almost the same as what is needed, this was a poorly designed and named property in the first place.
</soapbox>

I recognise and respect the backward-compatibility requirement. But I believe we should take the opportunity also correct the more obvious miss-steps so as not to confuse future adopters. My goal is to satisfy backward-compatibility while also moving people to a better option moving forward.

How to package DCAT-2014 is not yet resolved, and perhaps we could leave dcat:accessURL in the main DCAT ontology, with owl:deprecated "true". But leaving lots of deprecated elements in the DCAT-rev schema is undesirable, in my opinion.

I still disagree. We're haggling over a URI, accessURL versus accessService; in my mind, URIs are basically opaque strings -- you should not read any meaning into them, although human-readable strings may help implementers to remember them more easily. But you really should not expect anything from just looking at the URI.
What really matters is the definition of the term identified by a URI. In this case, the definition of accessURL is quite clear "A landing page, feed, SPARQL endpoint or other type of resource that gives access to the distribution of the dataset" -- note that it does not say "The URL of a landing page ....".
If we wanted to include services in the definition, we could decide to make a minor change to the definition, e.g. "A service, landing page, feed, SPARQL endpoint or other type of resource that gives access to the distribution of the dataset".
In my opinion, changing the URI to something that we find more elegant just for the sake of it is creating confusion where none is necessary.

I still disagree. We're haggling over a URI, accessURL versus accessService; in my mind, URIs are basically opaque strings

Yes, we are haggling over a URI (though maybe a little more to it - see below)

changing the URI to something that we find more elegant just for the sake of it is creating confusion where none is necessary.

I am concerned about who will be confused. I'm focussing more on the future market. And while it is in principle the case that definitions trump names (your argument about URI opacity) we also know that in practice we shouldn't expect people to read the documentation. Good names make things easier.

However, looking harder at the definition you quoted above, I wonder if in fact, the definition of accessURL is broader than what is needed for accessService ? In which case I would withdraw my proposal to deprecate accessURL, and rather just add accessService as a specialization or sub-property, with the definition "A service that gives access to the distribution of the dataset"

I support your proposal to add dcat:accessService as a sub-property of dcat:accessURL.

<soapbox>
I really think we should, at every opportunity and as clearly as possible, educate developers that it is really, really, seriously important to read definitions rather than make assumptions based on URIs or labels.
My 'good names' may not be the same as yours; words can be interpreted in many ways.
I've seen cases where different people made different assumptions based on a label without reading the definition and, in one case that I know of, this created serious interoperability problems.
</soapbox>

+1 to to add dcat:accessService as a sub-property of dcat:accessURL

I don’t believe an accessService fully subsumes an accessURL so we should not deprecate accessURL.

Still, I agree that property naming xxxURL is both bad modelling semantics and potentially misleading for devs.

+1 to the proposal of specializing dcat:accessURL with dcat:accessService

OK. Another observation: in the proposed model, the accessService link is a part of the DCAT 'backbone', which is something of a promotion compared with the role of accessURL inn DCAT-2014. i.e. its no longer just a link to an external resource denoted by a URL, its a link to a resource which is now a first-class part of DCAT, often listed in the same catalog.

In order to complete this, I think the definition and usageNote of accessURL should be modified, because they refer rather too strongly to URL, while we need the specialized usage to be a 'link' or possibly (rarely) a nested blank-node. I'm looking in the RDF representation.

Currently:

rdfs:comment "Could be any kind of URL that gives access to a distribution of the dataset. E.g. landing page, download, feed URL, SPARQL endpoint. Use when your catalog does not have information on which it is or when it is definitely not a download."

vann:usageNote "The value is a URL.
If the distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landing page link should be duplicated as accessURL on a distribution."

Proposed:

rdfs:comment "Link to a resource that gives access to a distribution of the dataset. E.g. landing page, feed URL, SPARQL endpoint. Use for all cases except a simple download link, in which case downloadURL is preferred."

vann:usageNote "If the distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landing page link should be duplicated as accessURL on a distribution."

Looks good to me.

+1 to the proposed rdfs:comment and vann:usageNote

Under the proposed model for services, I think dcat:accessURL should have the same value as the property-chain dcat:accessService , dcat:endpointURL . This could be expressed formally as a owl:propertyChainAxiom iff dcat:endPointURL is an owl:ObjectProperty. (Property chain axioms don't apply to Datatype properties.)

This might swing me round to keeping all the *URL properties as object-properties ... (see #249)

Resolved: no changes needed to domain and range. Add property-chain axiom

dcat:accessURL
  owl:propertyChainAxiom (
      dcat:accessService
      dcat:endpointURL
    ) .

Update the scopeNotes to clarify that it is a URL andd explain usage.
See https://www.w3.org/2018/06/14-dxwgdcat-minutes.html#x09