[Crm-sig] Fwd: Re: Symmetry of P130 and P139

Martin Scholz martin.scholz at informatik.uni-erlangen.de
Tue Apr 5 11:55:48 EEST 2011


Dear Martin,

let me respond to the raised issues.

firstly, on inverses:

There remains the inconsistent allocation of inverses for properties P130 and
P139. As both properties are described to behave the same regarding symmetry and 
P139 is a subproperty of P130, one would expect them _both_ to allocate inverses 
or _both_ to not allocate them.


Secondly, on symmetry:

The problem lies in the term "asymmetric". In German and at least some other 
languages, the term "asymmetric" is normally used in mathematics to refer to 
relations (a property is a binary relation) for which holds:

forall x,y in A: if R(x, y) then not R(y, x).

In English, "asymmetric" seems to be ambiguous as it is also used as a synonym 
for "nonsymmetric", ie. absence of symmetry.
(Cf. <http://en.wikipedia.org/wiki/Nonsymmetric_relation>) Obviously, in the CRM 
scope notes the term "asymmetric" is to be understood in that sense, ie. 
"nonsymmetric".

Therefore, I propose to change the word "asymmetric" to "nonsymmetric" as it is 
less misleading. Furthermore, I repeat the suggestion to explicitly define P130 
and P139 as nonsymmetric and to introduce symmetric subproperties if demanded.

Kind regars,
Martin Scholz


Am 01.04.2011 12:54, schrieb martin:
> 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 "dynamic-asymmetric".
> 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*(n-1)
>   >  "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. 53-57)."
>
> 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 CRM-compatible statements always many other CRM-compatible 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/Document-Monument.htm vs.
>> http://revealingmatrices.schich.info/fig/7/Document-Document.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 156-158).
>>
>> 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
>> bi-partite classification network, with similar objects on one side and
>> similarity criteria on the other (See Schich 2009* pp. 38-52). 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*(n-1)
>> "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. 53-57).
>>
>> 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.uni-heidelberg.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) 817-7880 | 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 short-cut 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
>>>
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>>
>
>


-- 
Martin Scholz, Dipl-Inf.
Artificial Intelligence Division
Department of Computer Science
University of Erlangen-Nuremberg
Haberstr. 2
91058 Erlangen

martin.scholz at informatik.uni-erlangen.de



More information about the Crm-sig mailing list