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

Michael Lodemann milo at
Fri Oct 10 01:49:45 PDT 2008

>> 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,
Can anyone tell me how to model such a property in an owl-ontology with

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

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

Of course you are right!

> 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"?

>> That brings me to the next problem - negotiation.
> You mean negation?

Yes I do - sorry.

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

Nice, what Thomas said about this issue.

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

Yes, now I understand this attempt a bit more.

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

Yes, when I got my example running I will post the whole OWL-file here.
Might be a good starting-point for others.
> , but if you
> are under a tight deadline working procedurally might be more
> familiar; it is for me.

I agree, it is for me as well. But I want to have all things together in
on OWL-file.

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

That is an important thought although I'm far away from dealing with such
big ammount of data.

Thanks again. I would appreciate if you can help me going further with
this mixed-up-property "curr_position(Sign, Sign.Position)".


More information about the protege-owl mailing list