Dxwg: Remove prof:BaseSpecification

[andrea-perego]

This issue has been already raised in https://github.com/w3c/dxwg/issues/404#issuecomment-438253648 , and partially discussed while preparing the ESWC paper.

The definition of this class is as follows:

A specification that defines all implementation constraints, without applying constraints on usage of another specification

IMO, this is an abstract scenario (is there any spec not using somehow another one?). And it is also said in the usage note:

This may not be a useful class: documents of any specification can be regarded as a trivial profile, so applications only need to be concerned with Profile conformance.

Moreover, its use in the PROF spec may lead to confusion. E.g.:

• The definition above implies that prof:BaseSpecification, but then it is defined as a subclass of prof:Profile (a particular type of profile with an empty set of constraints)
• In Figure 3, DCAT is said to be a prof:BaseSpecification. Is this correct, considering that DCAT re-uses classes and properties from other vocabularies?

Based on the considerations above, I would be in favour of dropping prof:BaseSpecification from PROF.

[nicholascar]

There may be use in having a Base Spec class for relative base-ness. I know this seems counter intuitive at first but:

From the point of view of DCAT-AP, DCAT may indeed be it's Base Spec. DCAT-AP may wish you to know about DCAT but not really about DC, OWL etc.

[kcoyle]

What is the functional use case for base specification? What does it tell you that you need to know and cannot know from the profile itself? Is the need for machines or for human users?

If there is no defined action that results from base specification then I agree with @andrea-perego that we should drop it. However, I also note that there are no properties in the ontology for descriptions, documentation, etc. It would seem to me that a profile should have at least the possibility of human-readable documentation, and that documentation could explain what key vocabularies or profiles the profile is based on, if the perceived need is for human understanding not machine processing. Admittedly, one or more of the resources of a profile may provide documentation, but that is at a resource level, not a profile level. For example, there may be documentation that looks like the current DCAP-AP, but that doesn't explain the relationship between DCAT-AP and the RDF file. Documentation at the inclusive level seems to be an obvious need.

[andrea-perego]

@nicholascar said:

There may be use in having a Base Spec class for relative base-ness. I know this seems counter intuitive at first but:

From the point of view of DCAT-AP, DCAT may indeed be it's Base Spec. DCAT-AP may wish you to know about DCAT but not really about DC, OWL etc.

We already have dct:Standard in PROF: cannot we use it for that purpose?

[aisaac]

I have many doubts about the class BaseSpecification too.
To me, 'base specification' in the current draft is not positing anything essential (where 'essence' is the notion from formal ontology) about the specification. Anything can be a 'base specification' as soon as it could serve as a base for a profile and it happens to not profile something else. In ontological terms, this notion of "base specification" is a role (albeit one defined negatively), not a type.
And that negative definition is shaky in an open world. It could be that a base specification is a "base specification" is said to be so because the creator of the description for the profile judged that a dependency of the "base specification" on another spec was not worth being represented. Or just as a result of an omission. As @andrea-perego claiming that DCAT is a BaseSpecification can be questioned as DCAT reuses elements from other vocabularies (for example SKOS).
I'd prefer to leave users find out what is such a "base specification" by querying for the instances of dct:Standard that are not the subject of prof:isProfileOf statements, just case-by-case, and based on available links, not types. Is there any requirement that needs us to reify a query for (absence of) prof:isProfileOf statements, with a class that has a debatable ontological ground?

And actually the problem of ontological grounding may be even worse. In fact @nicholascar 's answer about the DCAT example provides a good hint

From the point of view of DCAT-AP, DCAT may indeed be it's Base Spec.

This is saying that a "base specification" is defined from the perspective of the profile that profiles it. This is the other 'direction' than the current definition for BaseSpecification, which says

A specification that defines all implementation constraints, without applying constraints on usage of another specification

or even better the definition in the ESWC paper

prof:BaseSpecification: a dct:Standard that does not profile anything

Are we conceiving a "base specification" as something that's profiled by something, or something that doesn't profile anything else?

The original definition we have for profile

A named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function

Rather than trying to introduce a new understanding of what a "base specification" is, I think we should stick to that one, just accepted that it doesn't state anything on whether the base specification for a profile should (not) be a profile of something else.

And now for the final point: in this "original" view, prof:BaseSpecification would be anything that is the object of a prof:isProfileOf statement. But even if the meaning would be different from the "current" view, I would still not be convinced that we need a class, for a similar reason to the one I explained above. 'Reifying' the presence of a statement as a class brings us only more work and dubious ontological distinctions. In other words, this is a splendid opportunity to apply Occam's razor.

[rob-metalinkage]

I tend to agree... it was added partly in response to some difficulties and push back within the group discussions w.r.t understanding that a profile is a specification (standard) .. hopefully our sense of the nature of profiles has evolved enough now we no longer need this reminder,

i might argue about role vs class - and the challenges of defining sets in an Open World being dependent on the context of the user... but its not really important enough

I would support removing it, less is more. :-)

[nicholascar]

Happy with removal if we can do roles in place.

[andrea-perego]

@aisaac said:

I'd prefer to leave users find out what is such a "base specification" by querying for the instances of dct:Standard that are not the subject of prof:isProfileOf statements, just case-by-case, and based on available links, not types.

+1. This was also the sense of my note on dct:Standard in https://github.com/w3c/dxwg/issues/641#issuecomment-452478768

[andrea-perego]

@nicholascar said:

Happy with removal if we can do roles in place.

Can you provide an example of this, @nicholascar ? Personally, I don't think we need a role, but stick to what proposed by @aisaac earlier (a base specification is a dct:Standad which is not the subject of a prof:isProfileOf statement).

[nicholascar]

As it's written in the ontology, prof:BaseSpecification is a subclass of prof:Profile with a restriction on having zero prof:isProfileOf statements. @aisaac is saying the notion of a base spec should be emergent from queries.

Is it sensible to declare an owl:equivalentClass (as below) or just leave it out all together?

prof:BaseSpecification
  a owl:Class ;
  rdfs:subClassOf prof:Profile ,
  owl:equivalentClass [ 
    a owl:Restriction ;
    owl:onProperty prof:isProfileOf ;
    owl:maxCardinality "0"^^xsd:nonNegativeInteger
] ;

[aisaac]

I'd prefer to leave it out altogether as you can guess, @nicholascar .

If it has to stay, then I think owl:equivalentClass would be better.

In fact it's nice to see that the ontology is more precise than its spec. But then again, the question is whether the precision goes in the direction we were expecting. As our original definition of profiles is, and as intuition can lead us to think in some case (just like when you wrote "From the point of view of DCAT-AP, DCAT may indeed be it's Base Spec." above) one may instead expect the equivalent class to be:

prof:BaseSpecification
  a owl:Class ;
  rdfs:subClassOf prof:Profile ,
  owl:equivalentClass [ 
    a owl:Restriction ;
    owl:onProperty prof:hasProfile ;
    owl:minCardinality "1"^^xsd:nonNegativeInteger
] ;

Again i think I'd just prefer to have nothing rather than to try to fix all this. Unless there is a rela requirement that this class (in one or the other understanding) would help to meet.

[andrea-perego]

I agree with @aisaac .

[nicholascar]

Ok, I’ll put in a PR for @rob-metalinkage to review that removes the class.

[nicholascar]

This issue has been addressed in PR https://github.com/w3c/dxwg/pull/664

[kcoyle]

Let's give people a chance to review before closing. There was considerable interest in this change.

[nicholascar]

Closing after a week's listing as "due for closing" in Plenary 2019-08-27

[kcoyle]

@nicholascar The reason for closing needs to be the resolution of the issue. Above you say: "This issue has been addressed in PR #664" - however, that doesn't say HOW it was addressed. So something like "prof:BaseSpecification was removed from the document" would be more helpful, and that will also give better information for the management review as they are not going to want to wander through all of the comments to understand the resolution of issues. The clearer the closing comment the better for you in terms of supporting PROF.

[aisaac]

I'm reopening just as reminder for @nicholascar to add something like what @kcoyle suggested. This doesn't cost much and makes everything way better. (and I'm ok deleting my comment and @kcoyle 's one after that, so that the process discussion doesn't stay in the way of seeing the resolution)

[nicholascar]

Responding to @aisaac @kcoyle above:

The prof:BaseSpecification class has been removed from the vocabulary and thus the supporting documents with the recognition that the notion of a "base specification" is a term relative to a profile/standard and that an class (an absolute categorisation) is not needed. Where "base specification", in text, is mentioned in the documents, it is used to describe the role of a Profile/Standard in relation to another Profile via the second profiling the first.

Closing after listing in plenary 2019-09-03 + 3-day wait period.