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
Thu Oct 9 08:22:43 PDT 2008


On 9 Oct 2008, at 7:58 AM, Michael Lodemann wrote:

>> Well first you need to figure out the features of the sign which
>> determine its correct placement (with reference to the :Road
>> or :RoadSection).  I'm not sure how you do that with "Beware of
>> Kangaroos", unless you have other information about where a sign
>> should go.
>
> It's because it doesn't matter what is written on that sign. It  
> might be a
> "No Parking"- or a "Beware of Kangaroos"-sign or whatever. I just  
> want to
> make sure, that a sign belonging to a road-section is placed correctly
> somewhere on the road-section. Like: Sign.Pos >= RoadSection.Start- 
> Pos AND
> Sign.Pos <= RoadSection.End-Pos
>
>> With the distance to all the data you need to do the math
>> to determine whether the current placement of the sign (or the
>> position attribute of the sign) is correct.
>>
>> You want to get to here (untested and illustrative):
>>
>> curr_position(?sign, ?pos) ^ correct_position(?sign, ?correct) ^
>> swrlb:equal(?pos, ?correct) -> CorrectlyPlacedSign(?sign)
>
> 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.

> 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.

> 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 :)

> What about "?pos", "?star_pos" and "?end_pos"? In my ontology they
> currently are Datatype-properties of "Sign" and "RoadSection"
> respectively.
> Is it possible to handle it like this?

I don't think that SWRL is restricted to Object properties, otherwise  
what would swrlb:greaterThanOrEqual work with?  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.

>
> That brings me to the next problem - negotiation.

You mean negation?

> I can't model in SWRL that all not CorrectlyPlaced-Signs are
> MisPlaced-Signs, can I?

You might be able to, but I'd model misplacement directly, so you can  
tell if you have any corner cases left out.

> So do I have to create rules for every possible misplacement?

That's why I was suggesting a two-step approach, creating an  
intermediate property (:correct_position) for each :Sign.  It might  
make the individual rules for each class of sign more simple.

>> which requires a way of calculating the correct_position for
>> each :Sign.  For some that might be possible using the swrl math
>> transforms to generate a new statement (ie a SWRL result of ->
>> correct_position(?sign, ?calculated) )
>
> Sorry, I don't really get the need for the "correct_position"-Term.

It's an attempt to decomposition of the problem and so end up with  
simpler SWRL rules that are semantically clearer.

>> You might find that calculating the correct_position is best done
>> procedurally, accessing the knowledge base (ontology) via Jena or
>> similar.  That said by the time you are working procedurally you  
>> could
>> do the generation of the CorrectlyPlacedSign and MisPlacedSign
>> statements procedurally too, taking SWRL out of the equation.
>
> Hmm, I like SWRL, because you can store it together with the  
> ontology in
> one owl-file. What is the advantage of using sth. like Jena? Why not
> declarative programming? Just because of its complexity?

Yup, SWRL is good for that, and I encourage you to push on with it  
(perhaps sharing your experiences here when it works ;), but if you  
are under a tight deadline working procedurally might be more  
familiar; it is for me.  Also remember that using SWRL is going to  
require an SWRL capable reasoner; if your knowledge base + RAM needed  
for reasoning is greater than RAM for Java, you won't be able to load  
it into something like Pellet.  Probably not a limitation unless you  
are doing 100,000s of signs :)  Furthermore the speed can be a problem  
(although see Pellint for help there).  Procedural moves on the RDF  
(eg using CONSTRUCT sparql queries) are a sometimes a clunky, but good  
enough, way around such problems.

--J




More information about the protege-owl mailing list