Re: PROV-ISSUE-526: Data Model Section 5.5.2 [prov-dm]


thanks for the discussion, it does clarify but I feel it was indeed needed. By this I mean that the conflating of specialization 
with isa or subtype relationships, as James puts it, is going to be tempting to those who are not familiar with the finer points 
made by the definition, namely that of an "entity presenting more specific aspects of thing than another alternate entity". I am 
just worried that it may sound too exotic, for instance in the eyes of OO-savvy designers and developers, who do indeed think of 
specialization at class level.
Anyways this is not an objection as formally everything is fine, but it's another point where I see eyebrows raising


On 9/28/12 11:25 AM, James Cheney wrote:
> On Sep 27, 2012, at 10:20 PM, Graham Klyne wrote:
>> On 27/09/2012 19:58, Paolo Missier wrote:
>>> sorry it is consistent, I ignored inf. 20 (specialization implies alternate) and
>>> just assumed that two entities that belong to the same equivalence class should
>>> not be in a specialization hierarchy.
>>> But then I just realized I don't quite understand the point of Inf. 20: Why has
>>> it been introduced?
>>> you now have that specializations create equivalence classes, in particular
>>> a specializationOf b
>>> a specializationOf c
>>> implies a alternateOf b and a alternateOf c
>>> and therefore
>>> b alternateOf c
>>> which is a bit odd. For an OWL-inclined reader, specialization has a SubClassOf
>>> flavour, so this would be
>>> Mother specializationOf Woman
>>> Mother specializationOf Parent
>>> therefore Woman and Parent are "alternates" -- this seems to make the
>>> interpretation of "alternateOf" even more mysterious. Or is it just me
>> The above works for me.
>> If you adopt a class-oriented (OWL?) perspective, the alternateOf here would seem a bit odd.  But I'd see it applied to a single 
>> person, say Alice, a mother, when considering:
>>  Alice as a woman
>> and
>>  Alice as a parent
>> To me, these seem quite reasonable as alternativeOf views of Alice.
> Hi all,
> This seems to be revisiting ISSUE-29, whose resolution (I believe) agreed the definitions and inferences relating alternate and 
> specialization to each other.
> Inference 20 says that specialization is a kind of alternate.  This seems (to me) to follow from their English definitions [1]
>> An entity that is a specialization^◊ <> of another shares all aspects of the 
>> latter, and additionally presents more specific aspects of the same thing as the latter. In particular, the lifetime of the 
>> entity being specialized contains that of any specialization.
> ...
>> Two alternate^◊ <> entities present aspects of the same thing. These aspects may 
>> be the same or different, and the alternate entities may or may not overlap in time.
> So I think this issue can be resolved by adding explanation of the intended use of specialization (not as "subclass", but as 
> "entity presenting more specific aspects of thing than another alternate entity") and alternate (as "different aspects of the same 
> thing").  Perhaps additional remarks are needed to motivate the inferences in the constraints document too.
> I believe a conclusion of the resolution of ISSUE-29 was that other "part of" or "is-a" relationships were not to be conflated 
> with specialization - specifically, specialization does not necessarily align with containment in a collection or membership 
> between an instance and a class.  If we blur these distinctions, then we indeed get strange things (riffing on Paolo's example):
> Alice isa parent => Alice specializationOf parent => Alice alternateOf parent
> Bob isa parent =>  Bob specializationOf parent => Bob alternateOf parent
> ....therefore, by symmetry/transitivity....
> Alice alternateOf Bob.
> which is absurd.  So we should not (and currently do not) identify specialization with isa or subtype relationships (which are of 
> course handled in RDF/Owl already, and we should not reinvent).
> --James
> [1]
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.

-----------  ~oo~  --------------
Paolo Missier -,
School of Computing Science, Newcastle University,  UK

Received on Friday, 28 September 2012 14:08:25 UTC