PR for fixing #1394

[riccardoAlbertoni]

As suggested in issue #1394, and in the resolution https://github.com/w3c/dxwg/issues/105 This PR deletes from DCAT 2 serialization the axioms not explicitly mentioned in the DCAT 2 HTML REC.

I tried to track back where we decided to add these axioms ss suggested by Alejandra, issue #105 seems to play a role in many of them; perhaps @dr-shorthair or other editors have some more vivid memory about the discussion at the time.

Anyway, the PR deletes Axiom 1: all the dcterms:hasPart of dcat:Catalog to range in dcat:Resource

dcat:Catalog rdfs:subClassOf [
      a owl:Restriction ;
      owl:allValuesFrom dcat:Resource ;
      owl:onProperty dct:hasPart ;
    ] ;

This axiom could be implied by the range in https://www.w3.org/TR/vocab-dcat-2/#Property:catalog_has_part, but I am afraid we should have been more explicit on this to keep the axiom. I have not found a specific discussion on this in the DCAT 2 issue.

The PR deletes deletes Axiom 2: max one dcat:endpointURL is allowed in DataService

dcat:DataService rdfs:subClassOf [
      a owl:Restriction ;
      owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty dcat:endpointURL ;
 ] 

it is probably implied by the dcat:endpointURL definition "The root location or primary endpoint of the service (a Web-resolvable IRI) but not explicitly mentioned as axiom in the rec.

The PR deletes Axiom 3: at least one target should be specified for dcat:Relationship

dcat:Relationship
rdfs:subClassOf [
      a owl:Restriction ;
      owl:minCardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty dct:relation ;
    ] ;

As we discussed, we keep axioms that are reflected in the REC,

Axiom 4:

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

see rec at https://www.w3.org/TR/vocab-dcat-2/#Property:distribution_access_url

axiom 5

dcat:hadRole
  a owl:ObjectProperty ;
 rdfs:domain [
      a owl:Class ;
      owl:unionOf (
          prov:Attribution
          dcat:Relationship
        ) ;
    ] ;

see the domain defined at https://www.w3.org/TR/vocab-dcat-2/#Property:relationship_hadRole

Axiom 6:

dcat:CatalogRecord rdfs:subClassOf [
      a owl:Restriction ;
      owl:allValuesFrom dcat:Resource ;
      owl:onProperty foaf:primaryTopic ;
    ] ;
  rdfs:subClassOf [
      a owl:Restriction ;
      owl:cardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty foaf:primaryTopic ;
    ] ;

as it implements what is written in words in https://www.w3.org/TR/vocab-dcat-2/#Property:record_primary_topic

For discussion about what we are going to do with these axioms in DCAT 3, please refer to issue #1402

[davebrowning]

Note: When merged, this will (of course) update the files in the main branch which are mentioned in the released/current version of DCAT REC (at https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/#dcat-rdf - reference to DXWG code repository).

There is another copy of dcat2.ttl at https://www.w3.org/ns/dcat2.ttl mentioned in Section 6 ( https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/#RDF-representation) which I think needs to be updated. I suspect that might need W3 staff action.....? That copy is also referenced at https://www.w3.org/ns/dcat. That page also shows that there are copies of rdf and json-ld equivalents which need updated too....

(I'm not sure whether we can just do that or need some more formal process to sign off these updates/releases. If this isn't done then it'll just be confusing since we will have different versions of dcat2.ttl in different places......)

[riccardoAlbertoni]

Note: When merged, this will (of course) update the files in the main branch which are mentioned in the released/current version of DCAT REC (at https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/#dcat-rdf - reference to DXWG code repository).

There is another copy of dcat2.ttl at https://www.w3.org/ns/dcat2.ttl mentioned in Section 6 ( https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/#RDF-representation) which I think needs to be updated. I suspect that might need W3 staff action.....? That copy is also referenced at https://www.w3.org/ns/dcat. That page also shows that there are copies of rdf and json-ld equivalents which need updated too....

(I'm not sure whether we can just do that or need some more formal process to sign off these updates/releases. If this isn't done then it'll just be confusing since we will have different versions of dcat2.ttl in different places......)

I think we can ask Philippe to replace the RDF serialization referred in the REC.

I might be wrong but I think we already did the RDF replacement at least once after the publication of DCAT 2 rec.

Actually, the RDF served by https://www.w3.org/ns/dcat.ttl includes a dct:modified "2020-11-30"^^xsd:date , that suggests changes on the TTL has been made after the date of publication of DCAT 2 REC ;)

[davebrowning]

I think we can ask Philippe to replace the RDF serialization referred in the REC.

I might be wrong but I think we already did the RDF replacement at least once after the publication of DCAT 2 rec.

Actually, the RDF served by https://www.w3.org/ns/dcat.ttl includes a dct:modified "2020-11-30"^^xsd:date , that suggests changes on the TTL has been made after the date of publication of DCAT 2 REC ;)

Yes, I saw that too - I think we just need to remember to ask. (Item for the plenary? Would add it myself but I have to miss this weeks.....)

There is a separate discussion around https://www.w3.org/ns/dcat.ttl vs https://www.w3.org/ns/dcat2.ttl (I think they are identical) and whether this is what we intend, and what we want to do for DCAT3 but I need to remind myself what the W3 guidance says/check to see if it has changed at all before I log an issue.