Create no-orphaned-subclasses.sparql

[oliviahobai]

There is probably some trouble with lines 10-11. When it's convenient, could somebody else look at this file, please?

[swartik]

@oliviahobai

You can delete lines 9–11.

Also, that query isn't correct. My fault: I wrote it without fully understanding how github does error-checking. If all CCO classes have a parent class, the query shouldn't return any results at all. Unless someone beats me to it, I will provide a correct query in the next few days.

[swartik]

Insert before line 21:

   FILTER (?cls != <http://purl.obolibrary.org/obo/BFO_0000001>)

[swartik]

Delete lines 10 through 12.

[swartik]

Replace line 4 with:

#     All CCO classes must have a superclass.

[swartik]

Change Warning to Error.

[neilotte]

@oliviahobai @swartik

The present query returns classes that are:
a) not identical to BFO:entity,
b) IRIs
c) not subclasses of some class.

This query doesn't restrict the target IRIs to only CCO, nor does it rule out a class being a subclass of some other class (e.g. owl:Thing, skos:altLabel, etc).

I think the desired query is that every class in CCO should be a direct or transitive subclass of a BFO class. Here's an example. Let me know what you think.

`

Title:

No CCO class should fall outside the BFO hierarchy

Constraint Description:

All CCO classes must have a superclass in BFO.

Severity:

Error

PREFIX owl: http://www.w3.org/2002/07/owl#
PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema#

SELECT DISTINCT ?class ?label
WHERE {
?class a owl:Class .
FILTER contains(str(?class),"http://www.ontologyrepository.com/CommonCoreOntologies/")
FILTER NOT EXISTS {?class rdfs:subClassOf+ http://purl.obolibrary.org/obo/BFO_0000001 }
OPTIONAL {?class rdfs:label ?label}
}
`

[swartik]

@neilotte

The query I proposed addressed a specific bug in a CCO version. The alternative you propose is both more general (it addresses other potential problems) and more precise (it restricts itself to CCO). It will also detect class hierarchy errors in BFO releases, which is good.

The software engineer in me likes to isolate literals. I advise adding the prefix declaration:

PREFIX cco: <http://www.ontologyrepository.com/CommonCoreOntologies/>

and changing the first filter to:

FILTER contains(str(?class), str(cco:))

Function strstarts would be more accurate than contains – but some SPARQL engines don't implement strstarts. The engine Protege v5.5 uses is one of them.