Dxwg: Incorrect type for *URL properties - should be owl:DatatypeProperty with range xsd:anyURI

[dr-shorthair]

The properties dcat:accessURL, dcat:downloadURL and dcat:landingPage are currently specified as owl:ObjectProperty even though the description makes it clear that only a URI value is expected. The correct way to handle that is for them to be owl:DatatypeProperty with range xsd:anyURI.

Leaving them as owl:ObjectProperty means that an embedded/blank node is allowed, which is not the intention.

This pattern should also be used for the new property proposed for data services dcat:endpointURL (or dcat:endpointLocation - see #241

[dr-shorthair]

Maybe also dcat:landingPage.

[dr-shorthair]

Also see #124, #126

[dr-shorthair]

In https://github.com/w3c/dxwg/pull/241#issuecomment-394922932 @andrea-perego wrote:

@dr-shorthair said: I'm OK calling it endpointURL provided that for all the properties *URL, they are corrected to owl:DatatypeProperty with range xsd:anyURI

I have to disagree here. It would break existing implementations, and I don't think we have any use cases supporting this revision. Moreover, having them as object properties would enable cross-linking of related resources (as services and distributions). Using "URL" in the property name is consistent with similar DCAT properties (dcat:accessURL and dcat:downloadURL, which are object properties), and DCAT users will recognise the pattern. So, I don't see the need of requiring a term to be a datatype property just because it includes "URL" in its name.

[dr-shorthair]

@andrea-perego wrote:

It would break existing implementations,

I guess the problem is that the existing implementation have

dcat:downloadURL <http://www.example.org> ;

rather than

dcat:downloadURL "http://www.example.org"^^xsd:anyURI ;

That is definitely an incompatibility.

I don't think we have any use cases supporting this revision.

True. I'm primarily seeking consistency with the definitions, but of course that cannot be at the expense of functionality. And even if we do find some errors and infelicities, some we just have to accept as history.

Note that the documentation is ambiguous: in the RDF representation of DCAT-2014 in the definition of dcat:downloadURL there is a usage-note that says "The value is a URL" which would support my proposition. However, the comment says "This is a direct link ..." which is consistent with it being an object-property. If it is an object-property there is nothing in the RDF/OWL framework to stop it being a blank-node, which is inconsistent with the usage note. Maybe SHACL or ShEx could help?

Moreover, having them as object properties would enable cross-linking of related resources (as services and distributions).

I need to understand the details here. We have (provisionally) added a new property dcat:accessService to complement dcat:accessURL. If you are suggesting that accessURL can cross-link to a service description in the catalog (and not just to an external service endpoint) then there is no difference between them.

[dr-shorthair]

On the last point above, see https://github.com/w3c/dxwg/issues/124#issuecomment-395301407

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

[agbeltran]

I agree that the labels for the properties dcat:*URL and their descriptions would imply that their range should be xsd:anyURI making them owl:DatatypeProperty instead of owl:ObjectProperty.

However, I agree with @andrea-perego that we shouldn't break current implementations. We could move outside of OWL DL and support properties with the two types, but I don't think we should do that and add more complexity.

If the problem is the usage note, I suggest we change it to make clear that we expect the value to be an individual.

To find examples, I've been exploring the European Data Portal SPARQL endpoint. As @dr-shorthair mentioned, the current use is e.g. :
<http://europeandataportal.eu/set/distribution/dfdb9314-3695-45b5-b6e3-982c38a3f7aa> dcat:downloadURL <https://www.milieuinfo.be/dms/d/d/workspace/SpacesStore/480e10df-9020-41ce-ac38-c41bd98b5851/22.2.1%20Oostakker%20Slotendries.zip> ;

I could not find examples of 'cross-linking of related resources (as services and distributions)' (especially because the endpoint actually hangs with more complex queries). @andrea-perego maybe you can point us to examples of that?

[dr-shorthair]

I'm OK to withdraw this issue, primarily because of the backward compatibility issue. This was a historical mistake that it is too late to fix.

However,

1. the documentation and usage notes should be tightened up
2. the property-chain axiom that indicates the relationship between accessURL and endpointURL is a useful clarification for OWL people.

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

[agbeltran]

Yes, I agree we should keep backward compatibility and with the two points you mentioned. I can send a PR to fix the usage notes. Also, the point that @andrea-perego made about cross-linking with other resources could justify these properties being owl:ObjectPropertys.

[dr-shorthair]

Resolved - see https://www.w3.org/2018/06/14-dxwgdcat-minutes.html#x09