Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-owl] Modeling "for-each" in swrl

Thomas Russ tar at ISI.EDU
Wed Oct 15 10:29:47 PDT 2008


On Oct 15, 2008, at 4:47 AM, Michael Lodemann wrote:
>>
>> No.  The restriction is for classes.  But the class definition is
>> defined as an explicitly enumerated set of individuals.  This is the
>> owl:oneOf construct for class definition.
>
> But doesn't the oneOf construct implies, that just one of the  
> enumerated
> values describe the individual and not all? Speaking about the
> wine-ontology-example: A wine cannot be rose, red and white at the  
> same
> time.

The name may be a bit misleading, but what the oneOf construct means  
is that any individual that belongs to that class definition must be  
oneOf the given list.  In effect it describes a class that consists of  
exactly the set of enumerated individuals.  The way you have to  
interpret the name is that every individual in the class is "one of"  
the list of individuals.

If one writes a restriction like:

     class1 <=>  prop1 allValuesFrom {i1 i2 i3}

then class1 could have anywhere from 0 to 3 fillers of the prop1  
property, and the fillers can only be in the set {i1 i2 i3}.

In the wine ontology, the class WineColor is defined as {Red White  
Rose}.  That means that there are exactly three individuals that can  
be wine colors (since the individuals are declared to be  
allDifferent).  So there are three wine colors.

The reason an individual wine cannot be more than one color at a time  
is actually because the hasColor property is functional.  That is  
where the single value restriction comes into play.

Summarizing, the oneOf construct just creates a class defined as an  
enumerated set.

>>> Well, ok, you mean the RoadSections are part of the mentioned
>>> enumerated
>>> class, but what about the Road1-individual?
>>
>> The Road1 individual is defined to have as an additional type the
>> anonymous class defined by the restriction that all of the values for
>> the belongsTo property come from the enumerated set.  Using this or  
>> an
>> asserted cardinality restriction is the only way that you can limit
>> the fillers in OWL so that you can have a closed set of fillers for a
>> property.  I think, but am not completely sure, that the reasoners  
>> can
>> use cardinality restrictions along with a matching number of
>> allDifferent individuals to know that all of the fillers are present.
>
> Ok, I hope I modelled it correctly. Would you please verify it by  
> takeing
> a look at the attached screenshots?
>
> I think I did not do it well with the anonymous class of "road1". My  
> steps
> where:
> 1. Created a sub-class of Road "Road1_class" which has "{ road_sec11
> road_sec12 road_sec13 }" as Necessary&Sufficient condition

No, that is not quite correct.

What that does is say that the individuals in subclass are all  
RoadSections, but I don't think you want to say that RoadSections are  
Roads.

Instead, what you want to do is create an allValuesFrom restriction on  
the hasSection property and make the class argument be the  
enumeration.  I thought that this could be done when adding a type to  
an individual, but looking at the Protege interface, it doesn't seem  
as if it is possible to create an anonymous class when adding a type  
to an individual.  Perhaps I didn't find the right widget.

Anonymous classes like that are certainly allowed by the OWL language,  
it just doesn't appear to be part of the Protege GUI.

But what you would want to do if you can't use an anonymous class is  
create a subclass of Road with the following N&S condition:

    hasRoadSection allValuesFrom {roadSec_1, roadSec2, roadSec3}

> 2. "Add rdf:type" "Road1_class" to "road1"-Ind.
>
> It's because I don't know how to define an anonymous class defined  
> by a
> restriction and add that class as a type to the "road1"-ind. Would you
> mind to explain this stepwise to me in Protege 3.x?

Hmmm.  I guess I couldn't find a way to do that.

Perhaps one of the Protege folks could address this question.

> The dilemma of my not-so-anonymous-class "Road1_class" is, that I also
> have to write a specific rule for this and also for every other
> "Roadx_class", correct?

I'm not clear what you mean here by "rule".  You would have to write a  
definition for each such class.  You could adopt a naming convention  
like Road_1_Sections for the oneOf set of sections that belong to  
Road_1.  You would only need one SQWRL construct or SWRL rule for the  
ontology.  You would not need a separate rule for each such type.

> Next issue: The "belongsTo"-property has domain "roadSection". So I  
> need a
> reverse property "hasRoadSections" (D:Road) which values come from the
> enumerated set of roadSections, right?

Correct.





More information about the protege-owl mailing list