W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2007

Why the encapsulation?

From: Emanuele D'Arrigo <manu3d@gmail.com>
Date: Sun, 23 Sep 2007 13:08:17 +0100
Message-ID: <915dc91d0709230508w156443cvad35ef4ad28dd6c@mail.gmail.com>
To: "public-owl-dev-request@w3.org" <public-owl-dev@w3.org>

Hi there, newbie here, typing from the UK.

I'm in the process of evaluating the various SemanticWeb-related
technologies for the company I work for, with the aim at providing
recommendations for the architecture of the internal Asset Management
System (*).

I've read a fair amount of W3 documents on the subject but
there is something I don't quite understand in OWL and RDF.

Take the following property description from the OWL
Language Reference:

<owl:ObjectProperty rdf:ID="hasBankAccount">
 <rdfs:domain>
   <owl:Class>
     <owl:unionOf rdf:parseType="Collection">
       <owl:Class rdf:about="#Person"/>
       <owl:Class rdf:about="#Corporation"/>
     </owl:unionOf>
   </owl:Class>
 </rdfs:domain>
</owl:ObjectProperty>

Why the domain has to be declared as an anonymous
class and then as a union? Couldn't it be declared
simply like this:

<owl:ObjectProperty rdf:ID="hasBankAccount">
 <rdfs:domain>
       <owl:Class rdf:about="#Person"/>
       <owl:Class rdf:about="#Corporation"/>
 </rdfs:domain>
</owl:ObjectProperty>

What's the rationale behind the further encapsulation?

Manu

(*) I work in the Visual Effects/Computer Generated
Imagery field. For us an asset can be anything from
a file to a magnetic tape, from a DVD-R to a specific
computer, from a meeting room to a person. The
relationships between these assets are sometimes
static but often dynamic. A semantics-aware application
based on an amorphous network of triples sounds
like an extremely flexible approach but I have to
wrap my head around a few key issues (one of which
is the question above) and I have to evaluate if RDF
and OWL, as powerful as they are, are already too
powerful for our needs.
Received on Sunday, 23 September 2007 12:09:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:07:18 UTC