Re: PROV-ISSUE-29 (mutual-iVP-of): can two bobs be mutually "IVP of" each other [Conceptual Model]

On Mar 27, 2012, at 10:52 AM, Stian Soiland-Reyes wrote:

> alt1 and alt2 is good. It is fairly obvious (but should be explained
> in constraints) that alternateOf(a, b) indirectly implies
> alternateOf(b, a),

reasonable.


> as it implies
> 
> specializationOf(a, X)
> specializationOf(b, X)
> 

reasonable.


> and that implies:
> 
> alternateOf(b, a)
> alternateOf(a, b)
> 
> 
reasonable.


> Would we need to say that if
> 
>  alternateOf(a, b)
>  alternateOf(a, c)
> it does not imply:
> 
>  alternateOf(b, c)

reasonable.

-Tim


> 
> ?
> 
> 
> On Mon, Mar 26, 2012 at 22:46, Jim McCusker <mccusj@rpi.edu> wrote:
>> Do they need fully contextualized names? Can they just be a and b, or x and
>> y? I'm pretty sure this isn't a qualified relation...
>> 
>> Jim
>> 
>> 
>> On Mon, Mar 26, 2012 at 5:41 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>
>> wrote:
>>> 
>>> 
>>> BTW, has somebody got better names for first and second alternate?
>>> 
>>> 
>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd5-prov-dm-alternate.html#alternate.firstAlternate
>>> 
>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd5-prov-dm-alternate.html#alternate.secondAlternate
>>> 
>>> Thanks,
>>> Luc
>>> 
>>> 
>>> On 26/03/12 22:38, Luc Moreau wrote:
>>> 
>>> Hi Paolo,
>>> 
>>> I have updated the text to make it clear that the common entity does not
>>> need
>>> to be identified.
>>> 
>>> http://dvcs.w3.org/hg/prov/rev/21b96bf05727
>>> 
>>> Cheers,
>>> Luc
>>> 
>>> On 26/03/12 15:59, Paolo Missier wrote:
>>> 
>>> Luc
>>> 
>>> 
>>> On 3/26/12 2:54 PM, Luc Moreau wrote:
>>> 
>>> Dear all,
>>> 
>>> Thanks for your very useful suggestions.
>>> 
>>> I have drafted a revised section in a separate file
>>> 
>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd5-prov-dm-alternate.html
>>> 
>>> Does capture what has been discussed so far?
>>> 
>>> I think so. To me it is important that when we say
>>> " They are both specialization of an (unspecified) entity." eg in the
>>> first example, it is clear that there no obligation to say anything about
>>> the common entity that they specialize. This, however, contrasts with the
>>> definition itself:
>>> " An entity is alternate of another if they are both a specialization of
>>> some common entity."
>>> It is not clear what to make of this defining property of alternates -- it
>>> gives an existential condition which is not actionable in general. So to me
>>> this is potentially confusing.
>>> 
>>> 
>>> Also, if specialization(a,b) is it the case that alternateOf(a,b)?
>>> 
>>> no. I recall that we've been there before. At some point there was a
>>> discussion on specialization having a "top" and being transitive and
>>> therefore, with this additional inferences, everything would collapse.
>>> 
>>> Regards,
>>>   -Paolo
>>> 
>>> 
>>> Regards,
>>> Luc
>>> 
>>> On 25/03/2012 17:16, Timothy Lebo wrote:
>>> 
>>> 
>>> On Mar 25, 2012, at 9:43 AM, Jim McCusker wrote:
>>> 
>>> On Sun, Mar 25, 2012 at 3:18 AM, Graham Klyne <GK@ninebynine.org> wrote:
>>>> 
>>>> In my review comments which I think you have yet to get round to, I
>>>> question whether we actually need to have these concepts in the DM.
>>>> 
>>>> Originally, by my recollection, they were introduced to explain the
>>>> relationship between provenance entities and (possibly dynamic) real world
>>>> things.  With the looser description of the provenance model terms, I don't
>>>> see why this level of detail is needed in the data model.
>>> 
>>> 
>>> Then you don't recollect correctly.
>>> 
>>> 
>>> I remember IPV-of as the "relationship between provenance entities and
>>> (possibly dynamic) real world things", but specializationOf has developed
>>> into a more general association between entities that can include this
>>> original purpose. Indeed, eg-19 [1] is using alt and specOf for _exactly_
>>> this original "frozen snapshot of changing things" notion -- applied to
>>> datasets and web services.
>>> 
>>> Instead of digging up the archives, perhaps we can rally around altOf and
>>> specOf being the tools we use to associate (and make sense of) assertions
>>> made by the combinations of scruffy and proper provenance.
>>> (Like Simon's extension to Stian's BBC example). In addition, it's an
>>> incredibly useful construct for one's own "proper" modeling.
>>> 
>>> [1] http://www.w3.org/2011/prov/wiki/Eg-19-derived-named-graph-attribution
>>> 
>>> They were defined because there was an acknowledgement that there were
>>> multiple symbols that denoted a common thing in the world. Sometimes they
>>> reflected different aspects of the same thing (alternativeOf) and sometimes
>>> they had a subsumptive quality (specializationOf).
>>> 
>>> 
>>> I think these previous two statements contradict (and steer scarily
>>> towards owl:sameAs, which alt and specOf are certainly _not_)
>>> Different aspects of the same thing are not the same things.
>>> 
>>> -Tim
>>> 
>>> 
>>> Jim
>>> --
>>> Jim McCusker
>>> Programmer Analyst
>>> Krauthammer Lab, Pathology Informatics
>>> Yale School of Medicine
>>> james.mccusker@yale.edu | (203) 785-6330
>>> http://krauthammerlab.med.yale.edu
>>> 
>>> PhD Student
>>> Tetherless World Constellation
>>> Rensselaer Polytechnic Institute
>>> mccusj@cs.rpi.edu
>>> http://tw.rpi.edu
>>> 
>>> 
>>> 
>>> 
>>> --
>>> -----------  ~oo~  --------------
>>> Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
>>> School of Computing Science, Newcastle University,  UK
>>> http://www.cs.ncl.ac.uk/people/Paolo.Missier
>>> 
>> 
>> 
>> 
>> 
>> --
>> Jim McCusker
>> Programmer Analyst
>> Krauthammer Lab, Pathology Informatics
>> Yale School of Medicine
>> james.mccusker@yale.edu | (203) 785-6330
>> http://krauthammerlab.med.yale.edu
>> 
>> PhD Student
>> Tetherless World Constellation
>> Rensselaer Polytechnic Institute
>> mccusj@cs.rpi.edu
>> http://tw.rpi.edu
> 
> 
> 
> -- 
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> 
> 

Received on Tuesday, 27 March 2012 15:02:50 UTC