owl:someValuesFrom

<owl:Class rdf:about="http://www.liyangyu.com/camera#ExpensiveDSLR_1">
    <rdfs:subClassOf rdf:resource="http://www.liyangyu.com/camera#DSLR"/>
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty rdf:resource="http://www.liyangyu.com/camera#owned_by"/>
        <owl:someValuesFrom rdf:resource="http://www.liyangyu.com/camera#Professional"/>
      </owl:Restriction>
    </rdfs:subClassOf>
</owl:Class>

Then we have an instance defined (p. 168) as follows.

<myCamera:ExpensiveDSLR_1 rdf:about="http://dbpedia.org/resource/Canon_EOS-1D_1">
    <myCamera:owned_by rdf:resource="http://www.liyangyu.com/people#Tom"/>
</myCamera:ExpensiveDSLR_1>

The author claims then that following fact will be inferred.

<http://www.liyangyu.com/people#Tom> rdf:type <http://www.liyangyu.com/camera#Professional>

I checked this with Pellet and other reasoners but no one infers this.

The author forgets that we are working with an Open World Assumption. At any time someone else can come along with new information. So at this stage one is not certain that the only owner known is a Professional; hence no inference.

owl:someValuesFrom is used to infer subject from objects, not the other way around as the author claims.

owl:hasValue

<owl:Class rdf:about="http://www.liyangyu.com/camera#ExpensiveDSLR_2">
    <rdfs:subClassOf rdf:resource="http://www.liyangyu.com/camera#DSLR"/>
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty rdf:resource="http://www.liyangyu.com/camera#cost"/>
        <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
        >expensive</owl:hasValue>
      </owl:Restriction>
    </rdfs:subClassOf>
</owl:Class>

<myCamera:DSLR rdf:about="http://dbpedia.org/resource/Canon_EOS-1D_2">
    <myCamera:owned_by rdf:resource="http://www.liyangyu.com/people#Tom"/>
    <myCamera:cost rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
    >expensive</myCamera:cost>
</myCamera:DSLR>

The claimed inference:

<http://dbpedia.org/resource/Canon_EOS-1D_2> rdf:type  <http://www.liyangyu.com/camera#ExpensiveDSLR_2>

Again checking this with Pellet et all: no inference at all.

This is because the condition in the model is as follows:

Not the way around.

If you change the model to

<owl:Class rdf:about="http://www.liyangyu.com/camera#ExpensiveDSLR_3">
    <rdfs:subClassOf rdf:resource="http://www.liyangyu.com/camera#DSLR"/>
    <owl:equivalentClass>
      <owl:Restriction>
        <owl:onProperty rdf:resource="http://www.liyangyu.com/camera#cost"/>
        <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
        >expensive</owl:hasValue>
      </owl:Restriction>
    </owl:equivalentClass>
  </owl:Class>

then you get

Conclusion

;Load10=Hosting, hosting_php.dll

After installation

Virtuoso Service Manager

Virtuoso Server

Virtuoso Web Server

Loading RDF

Joseki/TDB

# Service 3 - SPARQL processor handling a TDB dataset
 <#service3>
 rdf:type joseki:Service ;
 rdfs:label "SPARQL on TDB" ;
 joseki:serviceRef "TDB" ; # web.xml must route this name to Joseki
 # dataset part
 joseki:dataset <#newdata> ;
 # Service part.
 joseki:processor joseki:ProcessorSPARQL_FixedDS .

## Initialize TDB.
[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
tdb:GraphTDB rdfs:subClassOf ja:Model .
<#newdata> rdf:type tdb:DatasetTDB ;
rdfs:label "A TDB dataset" ;
# location where the tdb.data folder exists
tdb:location "C:/Users/Paul/MyWorkSpaces/TBCMEWorkspace/Test/erfgoedplustdb.tdb.data" .

 <servlet-mapping>
 <servlet-name>SPARQL service processor</servlet-name>
 <url-pattern>/TDB</url-pattern>
 </servlet-mapping>

<form action="TDB" method="get">
<p>SELECT - get variables (apply XSLT stylesheet)</p>
<p><textarea name="query" cols="70" rows="5">
PREFIX pcce: <http://www.pcce.be/egb/>
SELECT ?a 
WHERE 
 { ?a a pcce:Germeente.}</textarea>
 <br/>

 Output XML: <input type="radio" name="output" value="xml" checked/>
 with XSLT style sheet (leave blank for none): 
 <input name="stylesheet" size="25" value="/xml-to-html.xsl" /> <br/>
 or JSON output: <br/>
 or text output: <br/>
 or CSV output: <br/>
 or TSV output: <br/>
 Force the accept header to <tt>text/plain</tt> regardless 
 <input type="checkbox" name="force-accept" value="text/plain"/>
 <br/>
 
 <input type="submit" value="Get Results" />
 </p>
 </form>

Starting Joseki

Testing Joseki

Exporting from TBC ME

Specific Query page to the TDB service

Joseki/BigOWLIM

# Service 4 - SPARQL processor handling a BigOWLIM store 
 <#service4>
 rdf:type joseki:Service ;
 rdfs:label "SPARQL on BigOWLIM" ;
 joseki:dataset otjena:bridge ;
 joseki:serviceRef "BigOWLIM" ;
 joseki:processor joseki:ProcessorSPARQL_FixedDS .

## Initialize BigOWLIM
[] ja:loadClass "com.ontotext.jena.SesameVocab" .
otjena:DatasetSesame rdfs:subClassOf ja:RDFDataset .
otjena:bridge rdf:type otjena:DatasetSesame ;
rdfs:label "BigOWLIM repository" ;
## BEWARE path to storage-folder not mentioned in manual
<http://www.ontotext.com/trree/owlim#storage-folder> "owlimTest-storage";
otjena:datasetParam "C:/Windows/System32/config/systemprofile/AppData/Roaming/Aduna/OpenRDF Sesame/repositories/bigowlimTest" . 

<servlet-mapping>
 <servlet-name>SPARQL service processor</servlet-name>
 <url-pattern>/BigOWLIM</url-pattern>
 </servlet-mapping>

Context

SELECT DISTINCT ?name (count( ?person) as ?total )
WHERE {
             ?person kennedys:gender ?gender.
             ?gender rdfs:label ?name.
             }
GROUP BY ?name
ORDER BY desc(?total)

which gives following result:

Testing

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step
    xmlns:p="http://www.w3.org/ns/xproc"
    xmlns:c="http://www.w3.org/ns/xproc-step"
    xmlns:cx="http://xmlcalabash.com/ns/extensions"
    name="myPipeline"
    version="1.0">
    <p:output
        port="result"
        sequence="true" />

    <!-- path to the folder with rdf files -->
    <p:variable
        name="path"
        select="'/Users/paul/Desktop/RandD/owlimimport/erfgoedplusImport/'">
        <p:empty />
    </p:variable>
    <p:directory-list
        include-filter=".*\.rdf">
        <p:with-option
            name="path"
            select="$path">
            <p:empty />
        </p:with-option>
    </p:directory-list>
    <p:for-each
        name="directoryloop">
        <p:output
            port="result"
            sequence="true" />
        <p:iteration-source
            select="/c:directory/c:file" />
        <p:variable
            name="file"
            select="concat($path,/c:file/@name)" />
        <p:load
            name="file">
            <p:with-option
                name="href"
                select="$file" />
        </p:load>
        <p:insert
            match="/c:request/c:body"
            position="first-child">
            <p:input
                port="source">
                <p:inline>
                    <c:request
                        href="http://api.talis.com/stores/zzzzzzzzz/meta"
                        method="POST"
                        detailed="true" auth-method="digest" username="xxxxxxx" password="yyyyyyy">
                        <c:body
                            content-type="application/rdf+xml" />
                    </c:request>
               </p:inline>
            </p:input>
            <p:input
                port="insertion">
                <p:pipe
                    port="result"
                    step="file" />
            </p:input>
        </p:insert>
        <p:http-request
            name="request"/>
        <p:identity />
    </p:for-each>
</p:declare-step>

Conclusion

Filtering untyped literals

<x>  pcce:city "Brussels"
<x>  pcce:city "Brussels"^^xsd:string 

My aim was to get rid of one of the two.

My initial idea was to make use of the SPARQL "datatype" operator, which returns the datatype IRI of the value.
My first SPARQL UPDATE query looked as follows:

DELETE {?a pcce:city ?city.}
WHERE {
   ?a  a pcce:Building.
   ?a  pcce:city ?city.
   FILTER (datatype(?city) != xsd:string) 
}

To my big surprise this didn't work at all.

I was kindly refered to the SPARQL spec by Scott Henninger of TopQuadrant, where is clearly indicated that if the parameter of the datatype operator is a simple literal, xsd:string is returned.

The built-in datatype operand in SPARQL casts untyped literals to xsd:string, so in both the cases xsd:string is returned making it impossible to check untyped literals this way.

Work-around

How is Literal Equality defined?

• The strings of the two lexical forms compare equal, character by character.
• Either both or neither have language tags.
• The language tags, if any, compare equal.
• Either both or neither have datatype URIs.
• The two datatype URIs, if any, compare equal, character by character.

What to compare?

Solution

DELETE {?a pcce:city ?city.}
WHERE {
   ?a  a pcce:Building.
   ?a  pcce:city ?city.
  FILTER (sameTerm(?city,xsd:string(?city))) 
}

Users of products from the TopBraid Suite family have access to a shortcut function for testing untyped literals: "spl:isUntypedLiteral".

Our query becomes then:

DELETE {?a pcce:city ?city.}
WHERE {
   ?a  a pcce:Building.
   ?a  pcce:city ?city.
  FILTER (!spl:isUntypedLiteral(?city)) 
}

• C&P's Pellet Integrity Constraint Validator which bundles in version 0.4 a skos-constraints.ttl file in the Examples directory
• TopQuadrant's recently announced SPIN implementation to be found at http://topbraid.org/spin/skosspin

• Merge similar names using multiple methods:
• Automatic title-casing
• using an expression language (GEL)
• using several clustering algorithms to detect similarities
• Split multi-valued cells over columns and rows
• Create new colums based on content of other columns
• ...

Make sure you see the videos at http://code.google.com/p/freebase-gridworks/

Some tricks I want to remember for myself:

• how to use regular expressions to correct cell values
• how to fill in a 'null' column with a value.

Correcting cell values using regular expressions

+ followed by the country code: e.g. +32
followed by the area code with the 0 between parentheses: e.g. (0)15
followed by the local code following this pattern X?XX XX XX: e.g. 23 45 67
Full example: +32 (0)15 23 45 67

The existing dataset contains slightly different phone numbers; shown as loaded into Gridworks.

Using regular expressions we can split the existing numbers in 2 groups using parentheses to indicate the groups:

• the characters before the area code
  start-of-line, followed by the '+' character, followed by 2 digits, followed by a space
  

  (^\+\d{2}\s)

• everything starting from the area code
  1 or 2 digits followed by a space, followed by multiple digits, followed by a space, followed by 2 digits followed by a space (2 times), followed by end-of-line
  

  (\d{1,2}\s\d+\s\d{2}\s\d{2}$)

The regular expression as shown in the RX Toolkit of Komodo IDE.

Now using these groups to replace the existing values with a value conforming the wished structure using the replacement expression
group 1 followed by '(0) followed by group 2.

\1(0)\2

Now that we have our regex working, let's move on to Gridworks now.

On the column containing the telephone numbers, choose Edit cells, Transform ...

Now we can use the Gridworks expression language (GEL) to do our transform.

GEL offers a whole list of functions; we will be using 'replace'. 'Replace' takes 3 arguments:

• the input string
• the replacement string which can be a regex
• the returned string after replacement which can contain the captured groups defined in the regex.

replace(value,//,'')

where value refers to the value in the cell
where // delimits the regex
and '' contains the replacement string using the captured groups being indicated with '$', e.g. $1, $2.

In our case the expression became:

replace(value,/(^\+\d{2}\s)(\d{1,2}\s\d+\s\d{2}\s\d{2}$)/,'$1(0)$2')

Filling in a column with a fixed value

forNonBlank(e, v, eNonBlank, eBlank)

• an expression to be evaluated
• captured in a variable
• when not null or empty string, evaluate eNonBlank
• when null or empty string, evaluate eBlank

In our case

forNonBlank(value, v, 'not relevant', 'museum')

Conclusion

Update: See similar post of Ric Roberts: Installing Jena, Joseki and TDB on OS X or Linux

Problem statement

• it is open source and free
• it is very easy to set up
• it has a very friendly user interface
• there is a built-in connector in Topbraid Composer ME; the chosen SW IDE
• and it is a national ('dutch') product.

SELECT COUNT(?person) AS ?alices
WHERE {
  ?person :name "Alice" .
}

• it is open source and free
• it is build upon the very robust Jena/ARQ RDF framework
• there is a built-in connector in Topbraid Composer ME, which uses the same Jena/ARQ RDF framework
• and offers support for SPARQL 1.1

Migration

1. Create from the Sesame store a TDB store
2. install Joseki
1. set environmental variables JOSEKIROOT and the JAVA CLASSPATH
3. Configure Joseki
1. adapt config.ttl to add the TDB store
2. adapt the web.xml file
3. make a HTML form for querying the SPARQL endpoint

Create a TDB store

Install Joseki

1. Unzip the distribution.
2. Set the JOSEKIROOT environment variable to the location of the installation.
   
   
3. Make sure your Java classpath points to %JOSEKIROOT%/lib
   
   
4. Test the installation by running from the command-line.
   
   
   Important: do not try to run the rdfserver bat file from the bin directory; run it directly from %JOSEKIROOT%.
   
   Point your web server now to http://localhost:2020/ and you should get this screen:
   
   

Configure Joseki

1. Add a service and a dataset to the joseki-config.ttl file (a service with name 'TDB' using dataset 'newdata').
   The joseki-config.ttl is found in %JOSEKIROOT%.
   

    # Service 3 - SPARQL processor only handling a given dataset
        <#service3>
        rdf:type            joseki:Service ;
        rdfs:label          "SPARQL on TDB" ;
        joseki:serviceRef   "TDB" ;   
   # web.xml must route this name to Joseki
        # dataset part
        joseki:dataset      <#newdata> ;
        # Service part.
        # This processor will not allow either the protocol,
        # nor the query, to specify the dataset.
        joseki:processor    joseki:ProcessorSPARQL_FixedDS ;
   

   and the settings for the 'newdata' dataset.
   

    ## Initialize TDB.
   [] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
   tdb:DatasetTDB  rdfs:subClassOf  ja:RDFDataset .
    
    <#newdata>   rdf:type tdb:DatasetTDB ;
    rdfs:label "A new TDB dataset" ;
    tdb:location "C:/Users/Paul/MyWorkSpaces/TBCMEWorkspace/Test/kennedys.tdb.data" .
   

2. add 'TDB' to the web.xml file which resides in %JOSEKIROOT\webapps\joseki\WEB-INF
   
   

   <servlet-mapping>
       <servlet-name>SPARQL service processor</servlet-name>
       <url-pattern>/TDB</url-pattern>
   </servlet-mapping>

3. make a HTML file (in my case myQuery.html containing a form to post queries to the TDB SPARQL service and copy it next to the other html files in %JOSEKIROOT%\webapps\joseki.
   
   

   <form action="TDB" method="get">
   <p>SELECT - get variables (apply XSLT stylesheet)</p>
   <p><textarea name="query" cols="70" rows="5">
   PREFIX kennedys: &lt;http://topbraid.org/examples/kennedys#>
   SELECT ?a  ?c
   WHERE 
     { ?a kennedys:name ?c}</textarea>
   	  <br/>
   	  Output XML: <input type="radio" name="output" value="xml" checked/>
   	  with XSLT style sheet (leave blank for none): 
   	  <input name="stylesheet" size="25" value="/xml-to-html.xsl" /> <br/>
   	  or JSON output: <input type="radio" name="output" value="json"/> <br/>
   	  or text output: <input type="radio" name="output" value="text"/> <br/>
   	  or CSV output: <input type="radio" name="output" value="csv"/> <br/>
   	  or TSV output: <input type="radio" name="output" value="tsv"/> <br/>
   	  Force the accept header to <tt>text/plain</tt> regardless 
    	  <input type="checkbox" name="force-accept" value="text/plain"/>
   	  <br/>
   	   
   	  <input type="submit" value="Get Results" />
   	  </p>
   </form>

Result

What happened previously

• S13: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties .
• S14: A resource has no more than one value of skos:prefLabel per language tag .
• S27: skos:related is disjoint with the property skos:broaderTransitive.
• S46 : skos:exactMatch is disjoint with each of the properties skos:broadMatch and skos:relatedMatch .
• S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel.
• S56: The property chain (skosxl:altLabel, skosxl:literalForm) is a sub-property of skos:altLabel.
• S57: The property chain (skosxl:hiddenLabel, skosxl:literalForm) is a sub-property of skos:hiddenLabel.
• S58: skosxl:prefLabel, skosxl:altLabel and skosxl:hiddenLabel are pairwise disjoint properties .

• S14: A resource has no more than one value of skos:prefLabel per language tag. Integrity constraints in SKOS (part 1)
• S13: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. Integrity constraints in SKOS (part 2)
• S27: skos:related is disjoint with the property skos:broaderTransitive. Integrity Constraints in SKOS (part 3)
• S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel. SKOS (part 4): property chains

• OWL is hard-coded against specific design patterns, and anything that goes beyond those patterns cannot be expressed.
• The choice of supported design patterns is heavily influenced by the theory of Description Logics being theoretically sound but the 'usefulness in practice' questionable.

• SPIN, the constraint and construct language developed by Holger Knublauch and implemented in the TBC suite of tools, but also available in open source
• OWL2 with an open world assumption as described by W3C and criticized by Holger
• OWL2 with a closed world assumption as implemented in Pellet ICV made by Clark & Parsia, from now on referred to as OWL2IC.

Do they disagree?

• in a lot of use cases the Open World Assumption of OWL2 is counter-intuitive and counter-productive (Why integrity constraints?)
• checking closed world constraints is best being done using SPARQL

• In the case of SPIN, you need to write the SPARQL yourself.
• In the case of OWL2IC, you write OWL axioms which are transformed then in the background to SPARQL queries.

• The writing of SPARQL queries is not that obvious. This is also one of the rationales behind the development of the Linked Data API. cf. slide
  So indeed, if well done, a declarative approach can make writing constraints easier for certain types of users.
  On the other hand is my experience and on the XML and RDF side that some constraints can only be expressed using rules; so I would say that this approach is more powerful, as being proved also in the context of S14.
  Easier versus powerful or maybe when we grow up, we get a combined solution such as in the upcoming XSD 1.1. (see also the suggestion of Evren Sirin in the context of S14.)
• SPIN is more than a constraint checking language, as being proved by the solution for the property chain inference which could not be expressed by OWL2.

Do they disagree?

Let the software speak

OWL-API and SKOS

If an ontology has an ontology IRI but no version IRI, then a different ontology with the same ontology IRI but no version IRI should not exist.

• S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel.
• S56: The property chain (skosxl:altLabel, skosxl:literalForm) is a sub-property of skos:altLabel.
• S57: The property chain (skosxl:hiddenLabel, skosxl:literalForm) is a sub-property of skos:hiddenLabel.

OWL2

SubObjectPropertyOf( ObjectPropertyChain( OPE1 ... OPEn ) OPE ).

• skosxl:prefLabel is an Object property.
• skosxl:literalForm is a Data property.
• skos:prefLabel is an Annotation property.

skos:prefLabel rdf:type owl:AnnotationProperty.
xl:prefLabel rdf:type owl:ObjectProperty.
xl:literalForm rdf:type owl:DatatypeProperty.

skos:prefLabel owl:propertyChainAxiom (
   xl:prefLabel
   xl:literalForm
   ).    

WARNING: Unsupported axiom: Bnode in owl:propertyChainAxiom axiom is not a valid
property expression.

SPIN

CONSTRUCT {
    ?this skos:prefLabel ?label .
}
WHERE {
    ?this xl:prefLabel ?prefLabel .
    ?prefLabel xl:literalForm ?label .
}

Conclusion

S27 skos:related is disjoint with the property skos:broaderTransitive.

OWL2

<rdf:Property rdf:about="http://www.w3.org/2004/02/skos/core#related">
    <rdfs:comment xml:lang="en">skos:related is disjoint with skos:broaderTransitive</rdfs:comment>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#SymmetricProperty"/>
    <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#semanticRelation"/>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
    <skos:definition xml:lang="en">Relates a concept to a concept with which there is an associative semantic relationship.</skos:definition>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
    <rdfs:label xml:lang="en">has related</rdfs:label>
    <owl:propertyDisjointWith rdf:resource="http://www.w3.org/2004/02/skos/core#broaderTransitive"/>
  </rdf:Property>

OWL2 DL

OWL2 DL does put however, for the reasons of decidability, some restrictions on the use of the DisjointObjectProperties axiom. The properties used need to be simple, meaning very roughly that axioms of following form cannot be involved (directly or indirectly):

• SubObjectPropertyOf( ObjectPropertyChain( OPE1 ... OPEn ) OPE ) with n > 1, or
• SubObjectPropertyOf( ObjectPropertyChain( OPE1 ... OPEn ) INV(OPE) ) with n > 1, or
• TransitiveObjectProperty( OPE ), or
• TransitiveObjectProperty( INV(OPE) )

Pellet 2.0

Indeed when using Pellet 2.0.2, we get following warning:

WARNING: Unsupported axiom: 
Ignoring transitivity and/or complex subproperty axioms for broaderTransitive
31-mrt-2010 14:09:54 org.mindswap.pellet.RBox ignoreTransitivity

SPIN

ASK WHERE {
    ?this skos:related ?object1 .
    ?this skos:broaderTransitive ?object2 .
    FILTER (?object1 = ?object2) .
}

Throwing errors as indicated in TopBraid Composer with following example:

Pellet ICV 0.4

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#related">
     <owl:propertyDisjointWith rdf:resource="http://www.w3.org/2004/02/skos/core#broaderTransitive"/>
  </rdf:Description>
   <rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#broaderTransitive">
     <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty"/>
  </rdf:Description>

reports correctly the constraint violation:

c:\Program Files\pellet-2.1.0>pellet-ic --constraints C:\Users\Paul\TBCMEWorkspa
ce\test\s27c.rdf C:\Users\Paul\TBCMEWorkspace\Test\s27.rdf
15-apr-2010 12:43:41 org.mindswap.pellet.jena.graph.loader.DefaultGraphLoader ad
dUnsupportedFeature
WARNING: Unsupported axiom: Ignoring transitivity axiom due to an existing disjo
intness axioms for property broaderTransitive
15-apr-2010 12:43:41 org.mindswap.pellet.RBox ignoreTransitivity
WARNING: Unsupported axiom: Ignoring transitivity and/or complex subproperty axi
oms for broaderTransitive
Validating 2 integrity constraints
Will stop after 1 constraint violation(s) are found

Validating constraint: related disjointPropertyWith broaderTransitive
Constraint violated  : Yes
Violating individuals (1): Concept_1,

Number of constraint(s) violated: 1

FYI: the SPARQL Query generated by Pellet ICV from the OWL Axiom above is:

SELECT  ?x0
WHERE
  { ?x1  skos:related          ?x0 ;
         skos:broaderTransitive  ?x0 .
  }

Conclusion

Once again fairly easy to do with SPIN;
a long study of the particularities of OWL2 DL restrictions to find out that this constraint cannot be expressed in OWL2 DL,
but OWL IC using the closed world assumption does the job also with 1 line of code.