Search Mailing List Archives
[protege-owl] Modeling Problem
milo at informatik.uni-kiel.de
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"
>> 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
> 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