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 Problem

James Howison james at howison.name
Fri Oct 10 07:48:52 PDT 2008


On 10 Oct 2008, at 4:49 AM, Michael Lodemann wrote:

>>> This one is a great hint. But I need sth like:
>>>
>>> curr_position(?sign, ?pos) ^ onRoadSection(?sign, ?road_sec) ^
>>> road_sec_start(?start_pos, ?road_sec) ^ road_sec_end(?end_pos, ?
>>> road_sec) ^
>>> swrlb:greaterThanOrEqual(?pos, ?start_pos) ^
>>> swrlb:lessThanOrEqual(?pos, ?end_pos) -> CorrectlyPlacedSign(?sign)
>>>
>>> Is this possible?
>>
>> Ah, you are now beyond my experiences with SWRL; I'm not actively
>> using it.  I hope others can help here.
>
> You already helped me a lot!
>
>>> And do "curr_position", "onRoadSection", "road_sec_start" and
>>> "road_sec_end" have to be (object)-properties in my ontology?
>>
>> They would have to be properties, but not object properties.
>
> But what else? There only do exist object- datatype- and
> annotation-properties, right? "onRoadSection" for me is clearly an
> object-property with domain "Sign" and range "RoadSection".
> But with "curr_position" it is not so clear, because domain is  
> "Sign" but
> range is "Sign.Position" which actually is a Datatype-property of  
> Sign,
> correct?
> Can anyone tell me how to model such a property in an owl-ontology  
> with
> protege?

I think it's simpler than you are suggesting.  I see it as this:

:curr_position rdf:type owl:DatatypeProperty ;
           rdfs:domain :Sign ;
           rdfs:range xsd:integer .

:curr_position is a Datatype Property, with a domain of :Sign and a  
range of integer.  I'm not sure what Sign.position would mean, in an  
owl world; a property is not 'attached' to a Class, as it is with  
Object Oriented programming.  If you wanted the position to be another  
Individual (in the OWL sense), with a class of :SignPlacement then it  
would be an object property (note the conventional change in the URI,  
using Capitalization rather than underscore to show an ObjectProperty):

:currPosition rdf:type owl:ObjectProperty ;
           rdfs:domain :Sign ;
           rdfs:range  :SignPlacement .

btw, remember that the first version here means that the reasoner can  
infer that anything that has a :curr_position property is a :Sign and  
the second version would have that and the inference that anything the  
property "points to" is a :SignPlacement

>>> And "CorrectlyPlacedSign" is a class as you described before, right?
>>
>> Yup, should result in adding statements of the form:
>>
>> ?sign rdf:type :CorrectPlacedSign .
>>
>> (I think, again I'm far from an expert, or even competent with  
>> SWRL :)
>
> But shouldn't "CorrectlyPlacedSign" be an infered class - so that
> statements (or instances of sign) are added by applying the SWRL- 
> Rule(s)?

Yeah, we are agreeing.  I'm just pointing out that "an inferred  
class" (for the URI) is indicated by adding a statement to the  
reasoned Model, such that any individual (a URI) that matched ?sign  
will now feature in a new statement:

eg, you assert:

:ind1 rdf:type owl:Resource ;
       rdf:type :Sign .

You write an SWRL rule which concludes with CorrectlyPlacedSign(? 
sign), where ?sign matched :ind1, and an OWL+SWRL aware reasoner (eg  
Pellet) now makes available a new statement (which exists alongside  
all the asserted statements).

:ind1 rdf:type :CorrectlyPlacedSign .

<snip>

>> SWRL is a way of
>> writing templates for triples.  So you can think about  
>> curr_position(?
>> sign, ?pos) taking each statement like:
>>
>> :ind1 :curr_position "some_pos" .
>>
>> and setting ?sign to :ind1 and ?pos to "some_pos" for use in the rest
>> of the rule.
>
> What do you mean with ":ind1"?

It's just shorthand for yourNS:individual1, probably I should have  
used :sign1.  It's any URI.

Sounds like you are well on your way.

hth,
James




More information about the protege-owl mailing list