[Crm-sig] Fwd: Re: Symmetry of P130 and P139
martin.scholz at informatik.uni-erlangen.de
Tue Apr 5 11:55:48 EEST 2011
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.
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.
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
> 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"
> 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 (!!!)
> 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?
> 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).
>> 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 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
>> * Schich 2009 see
>> Best regards,
>> 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:
>>> 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.
>>> 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
Martin Scholz, Dipl-Inf.
Artificial Intelligence Division
Department of Computer Science
University of Erlangen-Nuremberg
martin.scholz at informatik.uni-erlangen.de
More information about the Crm-sig