Re: viewOf / complementOf discussion in 201-12-15 telecon

Graham,

I guess while you were typing this, I was typing a new much simplified version of what I had in the PROV-DM internal draft, trying 
to capture the comments I heard.
So my take is independent from yours, however I don't think they are far apart at all.

I am basically suggesting to have two relations, viewOf and "foobar"  (I am deliberating avoiding the term "complement"), which 
together attempt to capture intuitions that I believe reflect your (1) and (2) below.

Then I am suggesting to saddle them with the properties (transitivity, symmetry) that we need to reflect their intended meaning -- 
again, I see no controversy, although you set (1) as non-transitive. fine by me if the others agree.

Then I say that /if/ validity intervals are known, /then/ a containment condition is necessary in order to preserve transitivity (at 
least in your case (2)).

That's it. You go further by suggesting a model-theoretical interpretation. I think this is a promising start but it belongs to a 
broader semantic model where the interpretation is grounded in some domain where concepts like "isAbout" are well-defined, as you 
point out.

The result is here:  http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-complement-of

Cheers,
  -Paolo




On 12/15/11 6:19 PM, Graham Klyne wrote:
> Paolo, and all,
>
> Re: viewOf / complementOf discussion in 201-12-15 telecon
>
> Prompted by discussion in today's teleconferences, and in particular by Paolo's
> articulation of the intuition behind "complementOf" (as was), here are some
> thoughts...
>
> It seems we have two competing intuitions, yet much of the contention is about
> naming and how to formalize or otherwise define them.  So I'd like to take the
> following approach:
>
> 1. describe the intuitions, with examples
>
> 2. assign names to the intuitions
>
> 3. discuss the extent to which they can be formalized, and how
>
>
> == Two intutiions ==
>
> 1. two entities that are constrained forms of the same real-world object; e.g.
>         (a) Bob as Twitter account holder
>         (b) Bob as Facebook account holder
>       or
>         (a) Luc in Boston
>         (b) Luc in Southampton
>
> I think this intuition is clearly symmetric and not, in general, transitive.
>
> The intuition has been further constrained in some discussions as requiring some
> overlap between the two entities, so the first example might apply, but the
> second would not.
>
> 2. an entity that is a constrained form of some other entity; e.g.
>         (a) Luc in his office
>         (b) Luc in Southampton
>     or
>         (a) Luc in Southampton
>         (b) Luc through his lifetime
>     or
>         (a) Luc in Boston
>         (b) Luc through his lifetime
>     or
>         (a) Bob as a Twitter account holder
>         (b) Bob as a computer user
>
> This intuition is transitive non-symmetric.
>
>
> == Naming ==
>
> For me, the name "complementOf" applies reasonably to the first intuition about
> two entities that are some facet of the same real-world entity.
>
> The term "viewOf" applies to the second intuition.
>
> I'll use these terms for the discussion that follows.
>
>
> == Formalization ==
>
> What can we say about these?
>
> Notation used below:
>     ':' such that
>     '==' defined as
>     '=>' implies (logical implication)
>     '|=' entails
>
> === complementOf ===
>
> We might capture the intuition thus:
>
> complementOf(a, b0 == exists r : isRealWorldThing(r) and
>                                    isAbout(a, r) and isAbout(b, r)
>
> but this begs a formalization of isRealWorldThing and isAbout
>
> Previously, there was an appeal to attributes, but that seems somewhat
> arbitrary, and for me not directly reflecting the original intuition.
>
> (I'm not sure where to go from here.)
>
>
> === viewOf ===
>
> I start by suggesting that an entity denotes a set of instances. Thus, when we
> talk about "Luc in Boston", we mean the set of all (instantaneous) instances of
> Luc for which Luc is in Boston.  This is presumed to be a primitive assertion
> (rather like a primitive class in a Description Logic).
>
> For some entity a, let us call this set instances(a) (somewhat as RDF formal
> semantics introduces a class extension ICext(c) to denote the members of a class c)
>
> Then we can formalize
>     viewOf(a, b) == forall(x) : x in instances(a) =>  x in instances(b)
>
> A corollory of this would be that if a provenance assertion A[p](a) is an
> assertion about a using some predicate p such that:
>
>     A[p](a) == forall(x) : x in instances(a) =>  p(a)
>          (i.e. A[p] asserts that p is true for all instances of a, which
>           captures the original notion we discussed months ago that
>           provenance assertions are invariant with respect to an entity)
>
> then
>
>     viewOf(a, b) |= A[p](a) =>  A[p](b)
>
> I think the transitivity of viewOf follows from the above.
>
>
> === viewOf and complementOf ===
>
> Given this formalism of viewOf, I think it is now possible to propose a more
> complete formalism of complementOf:
>
>     complementOf(a, b) == exists(x) : viewOf(x, a) and viewOf(x, b)
>
> <aside>
> Note that the existential x here replaces the need for the predicate
> isRealWorldThing, but is not necessarily itself a real world thing, whatever
> that may be.  We might try and define isRealWorldThing thus:
>
>     isRealWorldThing(x) == not exists(y) : isView(x, y)
>
> so one might say that real world things are anything that sit at the top of the
> isView hierarchy.
>
> Similarly, one might also define:
>      isAbout(a, b) == viewOf(a, b)
> </aside>
>
> This definition of complementOf does not capture the notion of overlap between
> complements.  But we could do that too, if needed, e.g.
>
>     strictComplementOf(a, b) == complementOf(a, b) and
>                                 exists(x) : viewOf(x,a) and viewOf(x,b)
>
>
> == Conclusion ==
>
> I believe this substantiates my previous claim that viewOf is somehow more
> fundamental.  Based on just a simple set-theoretic definition of viewOf, I have
> been able to construct a formal definition of complementOf.  But I don't believe
> it would be as easy to construct a primitive definition of complementOf and use
> just that to define viewOf.
>
>
> #g


-- 
-----------  ~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

Received on Thursday, 15 December 2011 18:50:00 UTC