Search Mailing List Archives
[protege-owl] Modeling Problem
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
> Can anyone tell me how to model such a property in an owl-ontology
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-
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 .
>> SWRL is a way of
>> writing templates for triples. So you can think about
>> 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.
More information about the protege-owl