Update class diagram according to #1470

[riccardoAlbertoni]

This PR updates the class diagram according to the changed made by #1470

• dcterms:hasPart has been added to dcat:Resource
• dcterms:hasPart linking dcat:Catalog to dcat:Resource is replaced by its subproperty dcat:resource It relates to #1320

Preview: https://raw.githubusercontent.com/w3c/dxwg/dcat-updateOfDiagram/dcat/images/dcat-all-attributes.svg

[andrea-perego]

Thanks, @riccardoAlbertoni .

I wonder whether we should take this opportunity to do some housekeeping of the image files. We have them in two different subfolders, namely, images and UML, and I'm not sure they are the same versions. This is confusing.

I think it would be better to keep all of them under the images subfolder and delete the UML one.

WDYT?

[andreasgeissner]

As you folks are working on the image already, may I just jump in and point out a typo? The connection dcat:DataService to dcat:Dataset reads dcat:serversDataset instead of dcat:servesDataset

[riccardoAlbertoni]

I have implemented the suggestions made by @andrea-perego:

• getting rid of UML directory
• removing from the diagram the inverse properties mentioned in section 7 as for #1413 and #1410

and I have fixed the typo serversDataset -> servesDataset thanks @andreasgeissner

[andrea-perego]

Thanks, @riccardoAlbertoni .

I think we should also remove the cardinality restrictions:

• The only cardinality restriction specified in the RDF concerns property dcat:record - to be decided whether to keep it or not
• The cardinality 1.. of dcat:resource (previously on dcterms:hasPart) is controversial (see discussion in https://www.w3.org/2022/02/22-dxwgdcat-minutes#t03), and should probably be revised into 0..
• Cardinalities as 0..* are the default ones, so they needn't be specified

[riccardoAlbertoni]

I think we should also remove the cardinality restrictions:

• The only cardinality restriction specified in the RDF concerns property dcat:record - to be decided whether to keep it or not

I would keep this.

• The cardinality 1.. of dcat:resource (previously on dcterms:hasPart) is controversial (see discussion in https://www.w3.org/2022/02/22-dxwgdcat-minutes#t03), and should probably be revised into 0..

I am ok with changing this.

• Cardinalities as 0..* are the default ones, so they needn't be specified

I am afraid without cardinalities some people might read 1 as default instead 0..* I think that the note below the figure explains quite well that cardinalities are not normative, and they are placed to provide usual expectations.

Let's discuss this in tonight's call. What is the harm that you see in keeping them? Anyway, If we cancel the cardinalities we need to change the note as well.

[andrea-perego]

@riccardoAlbertoni said:

• Cardinalities as 0..* are the default ones, so they needn't be specified

I am afraid without cardinalities some people might read 1 as default instead 0..*

Not sure about that. If no cardinality is specified, there are no cardinality restrictions. But we can clarify this in the note.

I think that the note below the figure explains quite well that cardinalities are not normative, and they are placed to provide usual expectations.

Yes, but if the cardinality is 0..* there is no need to make it explicit for the reason above.

Let's discuss this in tonight's call. [...]

Agreed.

[agbeltran]

@riccardoAlbertoni the dcat:Relationship part of the diagram has overlapping parts at the moment:

[dr-shorthair]

I am afraid without cardinalities some people might read 1 as default instead 0..*

Yes, that was the original motivation. In standard UML the default is 1..1

[riccardoAlbertoni]

@riccardoAlbertoni the dcat:Relationship part of the diagram has overlapping parts at the moment:

@agbeltran we have solved this and other glitches via e6788ef

[riccardoAlbertoni]

I am afraid without cardinalities some people might read 1 as default instead 0..*

Yes, that was the original motivation. In standard UML the default is 1..1

During the last DCAT meeting, we voted resolution 03 for the removal of all the cardinalities except those originally present in the RDF. The rationale is to reinforce the message that we do not normatively constraint them.

According to the meeting discussion, providing general expectations might be misleading in some cases, and by the way, cardinalities are not present for all the relations, which is another source of confusion.

e0f25df implements the voted resolution, dropping all the cardinalities and restating in the caption of the diagram that "Except where specifically indicated, DCAT does not provide cardinality constraints."

[andrea-perego]

The changelog needs to be updated accordingly (https://github.com/w3c/dxwg/issues/1471)