example showing why rdf:state is essential

I am trying to show that if rdf:states is not supported, once the "asserted" s-p-o triple is present, ALL existing and future "reified" s-p-o triples will now be considered as "asserted" (or occurrence of asserted triple). This limitation goes away if rdf:states is supported (along with rdf:reifies).

Consider the following "WorkHistory" data, shown in relational form.
StintID | EmpName | Company | StartYear | EndYear
============
1 | Bob', | 'A' | 1980 | 1990
2 | 'Bob' | 'B' | 1990 | 2000
3 | 'Bob' | 'A' | 2000 | 2010

RDF1.2: when rdf:states is NOT supported
======
# mapping from relational data (annotations not shown): NOT one-to-one
:stint1 rdf:reifies <<( :Bob :workedFor :A )>> . # R1
:stint2 rdf:reifies <<( :Bob :workedFor :B )>> . # R2
:stint3 rdf:reifies <<( :Bob :workedFor :A )>> . # R3
:Bob :workedFor :A . # A4
:Bob :workedFor :B . # A5

Addition of uncertain data:
========
# Adding the following triple to indicate that Bob might have worked for Company B, according to Alice
# This will be counted as "asserted" because of presence of triple A5 above (just like triples R1, R2, and R3)

:stint4 rdf:reifies <<( :Bob :workedFor :B )>> . # R4

RDF1.2: if rdf:states is supported, we can do it
======
# mapping from relational data: one-to-one
:stint1 rdf:states <<( :Bob :workedFor :A )>> . # S1
:stint2 rdf:states <<( :Bob :workedFor :B )>> . # S2
:stint3 rdf:states <<( :Bob :workedFor :A )>> . # S3

# R4 is counted as "reified" – there is no interference from any of the pre-existing triples
:stint4 rdf:reifies <<( :Bob :workedFor :B )>> . # R4

Thanks,
Souri.