Search Mailing List Archives
[protege-owl] Modeling Problem
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"
> 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
>> 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.
More information about the protege-owl