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

Michael Lodemann milo at
Wed Oct 22 03:20:50 PDT 2008


it took a while, because I'm fighting at a lot of borders. But I'm still 
stuck with this open-world-assumption problem not letting me to 
determine all roadSections of a road easily...
>>>> 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.
I think, it wasn't quite clear. I mean sth. like you wrote below.
>> 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.
I tried to understand and to model what you wrote. The following 
construct is the result:

  <owl:distinctMembers rdf:parseType="Collection">
    <j.0:Road rdf:ID="r1">
            <owl:oneOf rdf:parseType="Collection">
              <j.0:RoadSection rdf:resource="#r_section11"/>
              <j.0:RoadSection rdf:resource="#r_section12"/>
              <j.0:RoadSection rdf:resource="#r_section13"/>   
            <owl:ObjectProperty rdf:ID="hasRoadSection"/>

Do you mean it like this? Is a construct like that valid?
> 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}
Above I meant it like that, but with that approach I do need to form a 
seperate SWRL-Rule for each Road-individual in order to retrieve its 
roadSections, don't I? Or can I just retrieve them without any rules, 
because the specific roads with their sections are "hardcoded" and there 
is no need to infer them?

>> 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.
Hm, I can't really follow you. Can you give me a hint how to phrase the 
SWRL-rule for retrieving the road-relative roadSections out of the 
construct above?
> 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.
I don't get the purpose of the inverse properties. In the Pizza-Example 
there are for instance Pizza -> hasBase -> PizzaBase and PizzaBase -> 
isBaseOf -> Pizza. But this "isBaseOf" is not needed for any inferences. 
So what is it good for?

Still confused and hoping for a helping hand,

More information about the protege-owl mailing list