- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Mon, 17 Dec 2007 15:11:59 +0000
- To: www-archive@w3.org, Phil Archer <parcher@icra.org>, "Carroll, Jeremy John" <jeremy.carroll@hp.com>, Dan Brickley <danbri@danbri.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- CC: Ivan Herman <ivan@w3.org>, Bijan Parsia <bparsia@cs.man.ac.uk>
Jeremy Carroll wrote:
> - the subclass relationship
> I take the reified rdfs:subClassOf triple in the example that has
> circulated in earlier e-mail to be a response to a request to be more
> formal, or more OWL like, in response to the powder-dr WD. However, the
> design in the WD looks more user-friendly to me, if it could be made to
> work ...
So, I think the subClassOf in the example is somewhat flawed because the
resource set would need to be mapped into OWL as an intersection ....
1 <owl:Class rdf:ID="RC">
2 <comment>The class of resources on on example.org</comment>
3 <rdfs:subClassOf>
4 <owl:Restriction>
5 <owl:onProperty rdf:resource="&powder;#includeHost" />
6 <owl:hasValue>example.org</owl:hasValue>
7 </owl:Restriction>
8 </rdfs:subClassOf>
9 </owl:Class>
10 <owl:Class rdf:ID="Blue">
11 <comment>The set of all things that are blue</comment>
12 <datatype properties />
...
13 </owl:Class>
14 <rdf:Description rdf:about="#RC>
15 <rdfs:subClassOf rdf:resource="#Blue"
rdf:ID="assertion1" />
16 </rdf:Description>
17 <rdf:Description rdf:about="#assertion1">
18 <foaf:maker rdf:resource="http://example.com/foaf.rdf#david" />
19 <dcterms:issued>2007-12-04</dcterms:issued>
20 <wdr:validUntil>2008-12-03</wdr:validUntil>
21 ...
22 </rdf:Description>
So, in this code, the subClassOf in line 15 is relating the class #RC
introduced on line 1 to the class #Blue.
All it does is to reject possible interpretations which include non-Blue
resources from example.org within the class #RC; it does not force all
of the resources identified with URIs from example.org to be blue, which
is the probable intent.
That intent could be achieved, by turning the subClassOf on line 3 into
an owl:equivalentClass.
If we wanted to have an includeSchemes constraint as well, we would need
an owl:intersectionOf instead or the owl:equivalentClass ... etc. etc.
However, we are then turning the business of writing a POWDER document
into an expert OWL task, which seems completely inappropriate.
Jeremy
Received on Monday, 17 December 2007 15:12:33 UTC