Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove prof:BaseSpecification #641

Closed
andrea-perego opened this issue Jan 7, 2019 · 13 comments

Comments

5 participants
@andrea-perego
Copy link
Contributor

commented Jan 7, 2019

This issue has been already raised in #404 (comment) , 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

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 8, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

Happy with removal if we can do roles in place.

@nicholascar nicholascar added this to To do in Profiles Ontology via automation Jan 9, 2019

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

@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 #641 (comment)

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 10, 2019

I agree with @aisaac .

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2019

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

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2019

This issue has been addressed in PR #664

@nicholascar nicholascar removed the prof-2PWD label Feb 14, 2019

Profiles Ontology automation moved this from To do to Done Mar 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.