W3C home > Mailing lists > Public > public-owl-dev@w3.org > April to June 2008

Knowledge modeling question (required vs. optional)

From: Martin Becker <Martin.Becker@living-e.de>
Date: Wed, 21 May 2008 09:46:21 +0200
To: "public-owl-dev@w3.org" <public-owl-dev@w3.org>
Message-ID: <4653927E4BBD7E4AB436B8E05E8B5869052B6FCDFA@lisa.hq.living-e.zz>

Hello everybody,

I'm working on a OWL ontology that models the basic features of a well-
known German community portal. Each member of this portal has a user
profile, and some information of this profile is required, some
optional. However, for each field, only one item must be selected. How
can I represent this in OWL? Suppose a user held a job position, and
for that Position instance it is required that the company field is
filled out (while it is optional for this Position instance to have
the career level field specified).

My first idea for the required field was to use a combination of
owl:someValuesFrom and maxCardinality restriction set to 1 to say that
each Position instance must have at least (and obviously at most) one
Company instance. I'm not quite sure whether this might be equally
expressed by using a cardinality restriction (exactly 1). All I want
to say is that there must be a company selected, but only one, ie. you
cannot select more than one company.

le_xing:Position
      a       owl:Class ;
rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty le_xing:hasPositionCompany ;
                owl:someValuesFrom <.../companies#Company>
              ] ;
rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty le_xing:hasPositionCompany ;
                owl:someValuesFrom <.../companies#Company>
              ] ;

For an optional field I would then replace the owl:someValuesFrom
restriction by owl:allValuesFrom (keeping the maxCardinality =
1 restriction).

Does that make sense or do I need a qualified cardinality restriction
here?

Best regards,

Martin
Received on Wednesday, 21 May 2008 10:50:48 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:56 GMT