Dxwg: Inheritance terminology not appropriate for RDFS and OWL

[rawmatt]

4 places in the Recommendation refer to "_The following properties are inherited from the super-class_". The problem with this is that there is no concept of inheritance in the RDFS and OWL ecosystem.

From the OWL2 Primer:

Furthermore, OWL is a strictly declarative and logical language. OWL therefore has none of the operational aspects of OOP, like methods, and similarly reasoning in OWL is strictly logical, with nothing comparing to inheritance, particularly inheritance with exceptions or overriding. - https://www.w3.org/2007/OWL/draft/ED-owl2-primer-20090414/

In my opinion, referring to Sub-Properties as Inheritance is mis-leading. The term is not defined in the normative references, and therefore leaves the statement ambiguous.

My personal experience implementing DCAT v2 is using OOP terminology causes implementers to incorrectly assume normal OOP semantics.

Please consider removing OOP terminology and replacing with RDFS and OWL terminology.

[dr-shorthair]

Thanks @rawmatt you are strictly correct of course. This was loose language. The intention is merely to draw attention to properties associated with the super-class (through either global domain-range constraints, or local restrictions) which would therefore also be associated with sub-classes.

Would it be OK to write "The following properties associated with the super-class are also available for use."?

[rawmatt]

Yes, that would be OK.

How about: "The following properties of the super-class are also available for use." I suggest this because "associated" is undefined, and is also OOP terminology. "Of" is such plain English that I don't think it could be taken as implying anything extra.

[dr-shorthair]

@rawmatt I note that the section that you quote was in an appendix that did not survive into the final version of the Primer - is there a current reference I can use?

[rawmatt]

@dr-shorthair if the term is to be replaced, as you propose, why would it need a reference? Why reference an unused term or concept?

W3C Recommendations seem to state what things are, rather than what they are not. My understanding is nothing could be inferred from the absence of a statement in the final version of the Primer, only from what is present.

The issue is the term is undefined in the normative sections and references, and neither does it have its usual or common (OOP) meaning. The Primer is quoted as illustratory only; the Primer is not the source of the issue.

[dr-shorthair]

OK @rawmatt you are a good standards lawyer ;-) I've done a bit of that myself so can recognise and respect the argument. However, I was actually thinking that it might be useful to mention this argument in the (non-normative) note below the caption to this figure:
https://www.w3.org/TR/vocab-dcat-2/#UML_DCAT_All_Attr
which explains that the summary diagram is not UML.

[rawmatt]

Yes, I agree wholeheartedly about the diagram. My personal experience of implementing DCAT v2 is that the use of UML notation in Figure 1 reinforced the incorrect assumption of OOP semantics.

Today, I had the use of UML notation in that diagram quoted to me as justifying assuming OOP semantics.

That diagram uses UML Generalization to represent SubClassOf, which is conflating implementation inheritance with sub typing.

The Note say it "...uses UML-style class notation...", yet based on the UML Specification, I believe that the most apt UML Relationship is not UML Generalization, but is instead UML Substitution. If UML style notation is to be used, then it should be correct UML style notation.

[dr-shorthair]

Today, I had the use of UML notation in that diagram quoted to me as justifying assuming OOP semantics.

Did you point to the NOTE: ?

[rawmatt]

Yes - the NOTE is very helpful.

[dr-shorthair]

FWIW - There is plenty of precedent using open arrow-heads for sub-classes. See

• https://www.w3.org/TR/vocab-org/
• https://www.w3.org/TR/vocab-data-cube/
• https://www.w3.org/TR/vocab-dqv/

And also the standard IDEs (TopBraid, Protege visualization plugins).

I certainly see where you are coming from arguing for UML Substitution, but it is not widely known outside UML circles, the visual notation is messy (dashed connector with a stereotype), and it risks making the UML connection even stronger, so I'm disinclined to change horses.