1. n-ary relations OWL modeling problem when n≥3
E.g. complex events
Known solution with reification and binary projections
The situation content pattern and its specializations (time-indexed situations, various event models, etc.) are a good approximation, modulo argument ordering, and identity constraint
two new patterns: ordereddescription, and orderedsituation 1

2. ordered description pattern
enables to represent e.g.:
buys(x,y,z,t,p)
Buyer(x), Seller(y), Product(z),
Time(t), Place(p)
Person(x), Person(y)
Time(t*)
only contextual distinctions in basic n-ary pattern
no distinction in basic n-ary pattern! 2

3. ordered situation pattern
OWL2 punning here
for a version directed
at situations directly

4. still missing identity constraint
still misses identity constraint, e.g.
given the predicate: buys(x,y,z,t,p) [P1]
axiom A1 (identity constraint) holds: ∀(x,y,z,t,p)(buys(x,y,z,t,p) = buys(x,y,z,t,p)) [A1]
A1 is trivial in FOL
now, if P1 is morphed by the following predicates:
buys(r), buys1(r,x), buys2(r,y), buys3(r,z), buys4(r,t), buys5(r,p) [P2]
axiom A1 needs be morphed as follows (in case no list variables are present):
buys(r) ⟷ ∃!(x,y,z,t,p)(buys1(r,x) ∧ buys2(r,y) ∧ buys3(r,z) ∧ buys4(r,t) ∧ buys5(r,p)) [A2]
but axiom A2 cannot be expressed in OWL; we need either a rule, or a programmatic mechanism (e.g. a wizard, or a manual procedure) that ensures that any buys_n is functional
since OWA holds for OWL, no reasoner will infer that two individuals A and B occurring both in the place of e.g. x in buys1(r,x) are the same individual; it’ll only detect an inconsistency in case A owl:differentFrom B
still, this pattern does not ensure (in a model-theoretical way) that two instances B1 and B2 of buys(r) with the same relations to the same individuals are the same individual: for this additional inference, we need either a SPARQL or RIF formula (here a RIF example in next slide) 4

5. forall ?e
(?b1 [owl:sameAs :?b2] ←
and (
?e [:hasSetting ?b1]
?e [:hasSetting ?b2]
not (
?f [:hasSetting ?b1]
not (?f [:hasSetting ?b2])))
in case of list variables, a more complex pattern should be devised forall ?s ?e ?c 5

6. ... however ...
Many problem-solving tasks require reasoning over alternative conceptualizations of a same situation or a set of facts
classical problem: views, schema evolution, multiple ontologies over the same data, ontology matching, ...
traditionally, the universe of facts is not the same as the universe of concepts 6

7. ... however/2 ...
Semantic web and punning capabilities prove it’s important to have a clear shared universe of discourse
Also traditional “hard” tasks need it
legal knowledge (facts vs. cases vs. norms vs. meta-norms)
services, planning and control (actual vs. expected facts)
diagnoses and situation awareness (ground vs. (un)wanted facts)
hypothesis testing and CBR (building/testing interpretations from facts)
... 7

8. Situation classification
A common abstract task
“Classifying a situation” according to possibly incomplete, alternative or loose constraints and concepts
Constraints must be explicit and explicitly linked to the representation of a situation
descriptionandsituation pattern enables the representation of situations and descriptions, and their given links
entities of a situation that play roles from a description, values of a situation that fit parameters from a description, etc.).
But it's very hard to represent in general how to:
make a situation emerge out of scattered facts
decide if a situation can be (partly or fully) classified under a description
evaluate which description fits best a certain set of facts 8

9. Example I can get classification from this (also via rule)
RegularSale equivalentClass
(isSettingFor some
(isClassifiedBy some
(isConceptUsedIn value SaleModel)))
But I cannot state that each thing in the setting (or at least n things) must be classified by a concept that is used in SaleModel 9

10. D&S example isConceptUsedIn Seller Buyer Product Time Place SaleModel
isClassifiedBy
satisfies
Apple
Mustafa
iPad
Nov2010
Shanghai
Sale#1
isSettingFor
rdf:type
RegularSale

11. [1] OWL: minimal restriction or property chain
RegularSale equivalentClass
(isSettingFor some
(isClassifiedBy some
(isConceptUsedIn value SaleModel)))
(isSettingFor o isClassifiedBy o isConceptUsedIn) subPropertyOf satisfies

12. [1b] OWL: maximal restriction (does not work because of OWA)
RegularSale equivalentClass
(isSettingFor only
(isClassifiedBy some
(isConceptUsedIn value SaleModel)))

13. [2] OWL: detailed list of restrictions or property chains
RegularSale equivalentClass (
(isSettingFor some
(isClassifiedBy some
(Seller and (isConceptUsedIn value SaleModel)))
(Buyer and (isConceptUsedIn value SaleModel)))
(Product and (isConceptUsedIn value SaleModel)))
... )
property chain here needs special properties to chain, for each concept 13

14. [3] SPARQL
basic with SELECT or ASK; CONSTRUCT also possible to mimick a rule, but requires both positive and negative conditions
SELECT ?s
WHERE {
?s rdf:type :Situation .
?s:isSettingFor ?e .
OPTIONAL {?e :isClassifiedBy ?c . ?c :isConceptUsedIn :SaleModel } .
FILTER (!bound(?c)) }
OWL2 version
OPTIONAL {?e rdf:type ?c . ?c :isConceptUsedIn :SaleModel } . 14

15. [4] RIF OWL1 version OWL2 version forall ?s ?e ?c
(?s [:satisfies :SaleModel] | ?s [rdf:type :RegularSale] ←
and (
?e [:hasSetting ?s]
?e [:isClassifiedBy ?c]
?c [:isConceptUsedIn :SaleModel]))
OWL2 version
?e [rdf:type ?c] 15