[Crm-sig] Issue 230 Co-reference

Richard Light richard at light.demon.co.uk
Tue Apr 1 12:00:27 EEST 2014


I must confess that I have problems with this co-reference framework.

What I would expect us to be developing is a way of making statements 
that, in someone's opinion, this CRM entity X is (or is not) the same 
real-world entity as that CRM entity Y.  This is what I understand 
real-world co-referencing exercises do, e.g. aligning person identifiers 
in BNB with those in VIAF [1], using owl:sameAs or skos:exactMatch 
relationships.  The difference we would bring to current practice is 
that we would be providing an attribute assignment context which allows 
us to state who is asserting the co-reference, when they did it, etc., 
and allowing them to give their reasons.  Having "reified" the initial 
co-reference assertion, it would be possible for others to take issue 
with it, support it, etc.  Have I misunderstood the intention here?

If that is what we are aiming to develop, I would expect the 
co-reference assignment to be populated by two or more E1 CRM Entities, 
being the subjects of the co-reference statement. Instead, we have a 
situation where there is only one E1 CRM Entity, the "co-reference 
target", with E89 Propositional Objects being said to co-refer to it (or 
not).

In the example being discussed, I would prefer to say:

1. The word 'Passau' on my train ticket refers (in my opinion) to an E53 
Place X.
2. The first DHd conference took place in E53 Place Y.
3. X co-refers to Y.

Only assertion (3) is a co-reference statement; the other two are simply 
ways of defining E53 Places by stating their properties, so that the 
co-reference statement has some meaningful context.

A weakness of the current approach, in my view, is that it "finesses" 
one of the E1 CRM Entities involved, by only inferring it from an E89 
Propositional Object, rather than stating it explicitly. In many 
real-world cases, the entities to be co-referred will be identified by 
an E42 Identifier (e.g. a Linked Data URL), which would be disallowed by 
the current range of P153/P154.

What we currently have, in my view, is actually "reference", rather than 
"co-reference", i.e. a means of assigning an additional property to a 
single E1 CRM Entity.

Richard

[1] see e.g. http://bnb.data.bl.uk/doc/person/LightAlanR1950-.rdf

On 01/04/2014 00:27, Øyvind Eide wrote:
> On 30. mars 2014, at 21:25, martin wrote:
>
>> Dear Oeyvind,
>>
>> On 29/3/2014 10:13 πμ, Øyvind Eide wrote:
>>> It is quite possible that I do not understand what you say about P155. So this is my understanding of it:
>>>
>>> Co-reference assignment is about making explicit a fact which is assumed by the one making the assignment to be true.
>> Yes.
>>> An example:
>>>
>>> I claim that the word "Passau" on my train ticket and the place referred to by "city where the first DHd conference took place" both refer to the physical place Passau. If I make this statement in an information system, I would say:
>>>
>>> E91 Co-Reference Assignment P155 has co-reference target P53 Passau.
>>> (+ the other properties)
>>>
>>> The P155 points to the thing in the world to which the person making the co-reference assignment believes the references to point to.
>> Yes. How do I know that the URI (or whatever the range instance of P155 is) points to the Passau
>> I ment when I make this statement? This is why I said,
>> "The range of P155 can be interpreted as a URI (or whatever identity) used within the same knowledge base as the instance of E91. Then, it would correspond to a co-reference between some text element and the knowledge base in which we implement the CRM, the "local truth".
>>
>> It means, the Co-Reference statement shares the same reality (my understanding of the world )
>> as the identifier for "Passau" at p155. In other words, I know by sure how to relate this identifier to
>> the City in Bavaria. It could however be, that I refer to a URI for "Passau", which has been imported
>> in my knowledge base, and indeed was used for another Passau in another knowledge base which coined the URI. Then, my coref statement would be misleading. Indeed, it would be yet another co-reference, but this time to the use of a URI within a knowledge base, rather than a word within a text.
>>
>> All the magic is in your phrase: "The P155 points to the thing in the world". Whose world?
>>
>> Therefore, I'd suggest that P155 must point to an identifier of something the person who makes the
>> co-ref statement has an unambiguous notion of reality about, either a thing in the world by use
>> of an identifier the person "knows" to interpret, or pointing to a hypothetical thing "the thing referred in these two texts, whatever it is". In the latter case, it has an identity condition based on the text.
>> In any case, the scope note must make clear what difference is between P155 the other links in terms
>> of knowing. Therefore I proposed a "local shared truth" for P155.
>>
>> Opinions?
> Dear Martin,
>
> I think I understand now. But to make it clear if I do:
>
> in a normal reference situation, for instance (to go back to the situation of the example in CRM):
>
> E82 Hans Jæger (the name on the title page of the book) P131 identfies E21 Hans Jæger (the historical person)
>
> In that case the problem of reference you talk about does not apply.
>
> But in the situation:
>
> E91 Co-Reference Assignment P155 has co-reference target E21 Hans Jæger (the historical person)
>
> the problem does arise.
>
> The difference between the two situations is that in the former (P131) the reference is expressed in the model, whereas in the latter (P155) the references is expressed in a statement recorded in the model.
>
> Right?
>
> The questions is: do we need to record what the person making the co-reference statement believes the propositional objects refer to? The reference from each of them will/should/may be recorded in the system throught systems such as the various "identifies" properties.
>
>
> Best,
>
> Øyvind
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

-- 
*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20140401/2a29350b/attachment.html>


More information about the Crm-sig mailing list