[Crmsig] Symmetry of P130 and P139
martin
martin at ics.forth.gr
Fri Apr 1 13:54:30 EEST 2011
Dear Martin, Max,
Thank you for your observations.
Firstly, let me comment on symmetry:
The property P130 is asymmetric. Some specializations of it are
symmetric.
So: "A instance_of(P130)" does not imply "A instance_of(inv(P130))"
Let P130.1 be subproperty of P130, and symmetric.
Then "B instance_of (P130.1)" => "B instance_of (P130)" (subproperty)
"B instance_of (P130.1)" => "B instance_of (inv(P130.1)" (symmetry)
"B instance_of (inv(P130.1) => "B instance_of (P130.1). (symmetry)
So we can infer that
("For all B instance of(inv(P130.1))=> B instance of(P130)")
=> inv(P130.1) subproperty of (P130).
Where is the conflict?
You should not confuse "antisymmetric" with "asymmetric"
(http://en.wikipedia.org/wiki/Antisymmetric_relation)
Obviously, you cannot take asymmetry for antisymmetry, that would cause a
conflict. In our ,an asymmetric relation can have antisymmetric and
symmetric specializxations.
Secondly, we wrote "dynamic, asymmetric relationship", not "dynamicasymmetric".
By "dynamic" we mean one the user is encouraged to subtype according to local semantics.
This may not be a luccky term. Opinions on a better formulation welcome.
Thirdly, Max,
The point here is not to make a difference between similarity and derivation, but if
derivation implies similarity. The scope note of P130 states that derivation implies
similarity. It does not state that similarity is always due to derivation.
That "In real data there are up to two orders of
magnitude more instances for "similarity", than for any form of
"derivation" has nothing to do with the question, if derivation implies similarity.
Just the opposite.
Obviously, derivation should imply similarity of some kind. The reason to
have a superproperty of this form is that "in real data", we often cannot decide
if similarity is due to derivation or not. Even if it is due to derivation, we may
not know which one is the copy.
Your arguments about the difference of similarity and derivation are based on a causal
understanding of the process, which is in general not historical.
"In derivation data in general, it often makes sense to specify "unknown archetype" instances"
...of course! This is the whole idea of "FRBR Work".
If we resort to an archetype, the similarity is between the archetype and the product.
Then the parallel relations can be inferred. But they still are all P130.
Your phrase: "otherwise curators have to introduce n*(n1)
> "parallel copy" or "similarity" links in addition to all possible
> "derivative/influence" relationships back and forth the affiliation tree
>  which is crazy and therefore either almost never happens or carries a
> two digit error rate on behalf of database curators (See Schich 2009*
> pp. 5357)."
is a misunderstanding of the CRM, and of how the Semantic Web should (!!!)
work:
a) The CRM does not prescribe any statement to be made. The CRM is made to explain a statement.
Obviously, from CRMcompatible statements always many other CRMcompatible statements
may be deduced.
b) Inferences such as the propagation of a link that can be deduced from another, as
you describe here, is the job of a query module or a reasoner module, or both, and
not of a crazy curator. It is impossible to normalize "real data" to a solution that
avoids reasoning. Obviously, data should be documented in a way that takes the capability
of reasoning into account.
Any objections?
Best,
Martin
On 3/31/2011 10:30 PM, Maximilian Schich wrote:
> Dear Martin, Martin, and all,
>
> This is may be in contradiction with CIDOC philosophy, but might help to
> solve the issue:
>
> Similarity and Derivation:
> Practically, it does not make sense to put "similarity" and "derivation"
> into the same property. In real data there are up to two orders of
> magnitude more instances for "similarity", than for any form of
> "derivation" (See for e.g.
> http://revealingmatrices.schich.info/fig/7/DocumentMonument.htm vs.
> http://revealingmatrices.schich.info/fig/7/DocumentDocument.htm ).
>
> For a basic understanding of the difference between similarity and
> derivation see also George Kubler: The Shape of Time. 1962 including
> Oystein Ore's note 3 on p. 33 (cf. Schich 2009* pp 156158).
>
> Similarity:
> As "similarity" usually works "across given criteria"  for e.g. two
> drawings being similar using the same technique, or showing the same
> monument  similarity data should be represented and collected as a
> bipartite classification network, with similar objects on one side and
> similarity criteria on the other (See Schich 2009* pp. 3852). P130 does
> not allow for such a model, as it only establishes a relationship
> between two similar objects.
>
> Derivation:
> Derivation is best modelled as a directed network, either shortcut with
> simple links (P130/P139) or with "derivation events" between two objects
> dependent on each other.
>
> In derivation data in general, it often makes sense to specify "unknown
> archetype" instances  otherwise curators have to introduce n*(n1)
> "parallel copy" or "similarity" links in addition to all possible
> "derivative/influence" relationships back and forth the affiliation tree
>  which is crazy and therefore either almost never happens or carries a
> two digit error rate on behalf of database curators (See Schich 2009*
> pp. 5357).
>
> Influence vs. Citation:
> For practical reasons, the link between archetype and derivative work
> should always point to the past  i.e. CIDOC should recommend P130, not
> P139 (see Baxandall 1985 "Patterns of Intention" s.v. "Excursus against
> Influence).
>
> * Schich 2009 see
> http://archiv.ub.uniheidelberg.de/artdok/volltexte/2009/700/pdf/Schich_RezTra_2009.pdf
>
> Best regards,
> Max
>
>
> Dr. Maximilian Schich
> DFG Visiting Research Scientist
> CCNR  BarabásiLab  Northeastern University, Physics Dept.
> 110 Forsyth St., 111 Dana Research Center  Boston, MA 02115
> tel.: +1 (617) 8177880  skype: maximilian.schich
> mail: maximilian at schich.info  home: www.schich.info
>
>
>
> Am 31.03.11 13:13, schrieb Martin Scholz:
>> Dear All,
>>
>> the scope notes of P130 and P139 are as follows:
>>
>> P130:
>> This property generalises the notions of "copy of" and "similar to" into a
>> dynamic, asymmetric relationship, where the domain expresses the derivative, if
>> such a direction can be established. Otherwise, the relationship is symmetric.
>> It is a shortcut of P15 was influenced by (influenced) in a creation or
>> production, if such a reason for the similarity can be verified. Moreover it
>> expresses similarity in cases that can be stated between two objects only,
>> without historical knowledge about its reasons.
>>
>> P139:
>> This property establishes a relationship of equivalence between two instances of
>> E41 Appellation independent from any item identified by them. It is a dynamic
>> asymmetric relationship, where the range expresses the derivative, if such a
>> direction can be established. Otherwise, the relationship is symmetric. The
>> relationship is not transitive. The equivalence applies to all cases of use of
>> an instance of E41 Appellation. Multiple names assigned to an object, which are
>> not equivalent for all things identified with a specific instance of E41
>> Appellation, should be modelled as repeated values of P1 is identified by
>> identifies). P139.1 has type allows the type of derivation, such as
>> "transliteration from Latin 1 to ASCII” be refined..
>>
>>
>> Both scope notes state that the properties are dynamic asymmetric, i.e. may be
>> both symmetric and asymmetric, depending on the type of relation the property
>> instances resemble.
>> This is misleading and calls for clarification, as
>> a) the term dynamic asymmetric relation is not defined
>> b) from a mathematical/logical point of view, a relation may not be both
>> symmetric and asymmetric. (but it may be neither sym. nor asym.!)
>>
>> Furthermore, P130 defines an inverse property while P139 does not. This is
>> inconsistent. If both properties are regarded as symmetric, the inverse of P130
>> should be removed. If both are not symmetric, an inverse should be added to P139.
>> A solution could be to define P130 and P139 as not symmetric and include inverse
>> properties for both. If symmetric properties are needed, new (sub)properties of
>> P130 and P139 need to be introduced which are then marked as symmetric and
>> without inverses.
>>
>>
>> Kind regards
>> Martin Scholz
>>
> _______________________________________________
> Crmsig mailing list
> Crmsig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crmsig
>
>


Dr. Martin Doerr  Vox:+30(2810)391625 
Research Director  Fax:+30(2810)391638 
 Email: martin at ics.forth.gr 

Center for Cultural Informatics 
Information Systems Laboratory 
Institute of Computer Science 
Foundation for Research and Technology  Hellas (FORTH) 

Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece 

Website: http://www.ics.forth.gr/isl 

More information about the Crmsig
mailing list