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

Hi Paolo,

In this message, I'll try and figure out where any remaining disagreements may lie.

Short version:  apart from small specific issues noted, I'm happy with your text 
at 
http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-complement-of. 
  The main difference of view seems to be about transitivity of [foobar].  I'd 
be happy to see transitivity of viewOf as a given, with deeper formalization to 
be treated separately from the data model (e.g. the formal semantics).

Longer version interleaved:

On 17/12/2011 15:25, Paolo Missier wrote:
> Graham,
>
> comments interleaved, as usual.
>
> On 12/16/11 10:44 AM, Graham Klyne wrote:
>> Paolo,
>>
>> Summary: I think we are converging here. Your revised text is looking pretty
>> good to me, modulo small details and nits.
> the small bits I am taking care of, no problem.
>> ...
>> Rather than respond to your email, I'll comment on your updated document:
>>
>> Section 5.3.3.3
>>
>> "1. e2 provides a more concrete characterization of Bob than e1 does" - I don't
>> see this. Did you mean e2 (Bob+twitter) more concrete than e3 (Bob+person)?
> sorry that should have been e2 .. e3

>> "foobar(B,A) is transitive: foobar(C,B) and foobar(B,A) implies foobar(C,A)." I
>> think it's only transitive if you do not require any overlap for [foobar].
> this is a bit surprising. I am trying to capture the indications from several
> people, but I still hear contrasting requirements. I thought we had agreed that
> interval containment is a necessary condition for transitivity??

I'm not sure which discussions these were.  "interval containment" sounds to me 
like the intent of "viewOf" based on temporal extents.  On that basis, I'd say 
"sufficient" rather than "necessary".

But, for [foobar] (and appealing to my previous notion of instances), if overlap 
is needed, then suppose we have:
    A and B overlap with instance(s) ab
    B and C overlap with instance(s) bc
with no common instance between ab and bc.  Then A and C do not overlap.  If 
overlap is a requirement for [foobar] then we have:
   not foobar(A,C)
despite having:
   foobar(A,B) and foobar(B,C)
hence foobar is not transitive.

OTOH, if foobar does not require overlap, and if any entity may be about at most 
one real word thing,

   foobar(A,B) means that A and B are about some X
   foobar(B.C) means that B and C are about some Y

but if B is about X and Y, X == Y, therefor A and C are also about the same real 
world thing, hence foobar(A,C).

Of course, all this depends upon some notion of any entity being about only one 
real world thing.  Without that assumption, I don't see a way top claim 
transitivity for foobar.

I'd be happy to say nothing about transitivity of foobar.

> What I have done is to take into account the observation we all made, that
> validity intervals are not always known, and so I broke down the definition into
> - the properties that what we want: transitivity + anti-symmetry for viewOf, and
> transitivity + symmetry for foobar.
> - the containment condition on the intervals /when they are available./

Hmmm... let's go case by case:

viewOf: transitive - I agree
viewOf: anti-symmetric - I agree, assuming reflexivity as well; i.e. viewOf(A,A)

foobar: transitive - see above
foobar: symmetric - I agree

In particular, I do not think that transitivity of foobar depends on containment 
of intervals (when they are available).

<aside>
Talking about containment of intervals "when they are available" feels awkward 
to me.

If we are to talk about intervals, I'd rather deal with this through an 
existential claim:

viewOf(A,B) |= exists interval(A) and exists interval(B) :
                  interval(A) in interval(B)

but this does make viewOf a stronger condition that that implied by the 
formalism based on instances.
</aside>

>> "Let val(e) denote the validity interval of e." Nit: I find the choice "val(e)
>> potentially confusing; too much like "value", would prefer "validity". Also, is
>> there any danger of confusion with logical validity? (I think not, just asking.)
> how about "characterization interval"? we don't really need a function name for
> this, it was just an abbreviation.

This was just a nit.  I'd rather stick with a function here.  I think calling it 
"characterization interval" raises more questions than it answers.

...

>> The main difference between your revised proposal and mine that I see is your
>> appeal to the validity interval where I appeal to an instances set. But at the
>> level of abstraction stated, I think they are formally different by just a
>> change of name - your "val" performs the same role as my "instances". The
>> difference is in "val"s intuitive appeal to a time interval, which I can live
>> with (as in voting "-0") as I think this is the main case we'll come across in
>> practice.
> ok, I think this duality of "validity intervals" and "instances" reveals a
> deeper issue that has to do with the connection between the semantics (which we
> haven't really spelled out officially) and the way it is manifested in
> constraints at the level of our assertion language.
>
> Firstly, I do /not/ intend to appeal to validity intervals -- that was rather
> Stephen's idea. I am just going with it as a way to reconcile our views.

OK, sorry, I should have said "your proposed text" - I didn't mean to 
personalize the point.  (But for myself I'd say less, not more.)

> "characterization" intervals have been introduced long ago in early discussions,
> but the language is not clear about them.

Indeed, I never greatly liked that approach, but I'd live with it on the basis 
that I think most practical cases would depend on interval containment (except, 
maybe, my workflow example).  (I assume here that an "interval" means a "time 
interval", or at least an interval over some independent variable.)

> ... Entity records do not even have a
> syntax for them. In particular we haven't defined what happens to an entity
> record outside of its "validity interval". Unless there is a formal definition I
> would just avoid mentioning them altogether.

That suits me :)

> ... You do indeed propose a definition
> that avoids intervals and relies instead on a class/instances framework.
>
> Introducing instances is appealing because it gives you a grounding for the
> semantics of relations such as viewOf, however it still does not give us a set
> of constraints that we can enforce: there is no manifestation of instances in
> our assertion language. So the interpretation you propose is fine but it doesn't
> seem to translate into necessary conditions that can be enforced on our assertions.
> This is what I think is missing. So I am going back to my earlier attempt at
> using attibutes. More specifically:
> Would it be possible to add to your fundamental definition:
>
> viewOf(a, b) == forall(x) : x in instances(a) => x in instances(b)
>
> a characterization of instances(x) in terms of our language constructs?

Maybe: I don't know.

We need to start from some premises.  Previously, when you mentioned "saddling" 
the relations with some properties, I assumed you were suggesting to treat 
transitivity of viewOf as a premise, and I'm fine with that.

My suggested formalization of viewOf was a parallel effort to try and better 
understand the competing intuitions.

Looking back, I think the treatment of "instances" could belong in the formal 
semantics rather than in the data model.  It doesn't prevent us from defining 
[foobar] in terms of viewOf (as I did for complementOf).  I think it's fine that 
there is no notion of instances in the data model - they may be just a notion of 
the attendant metatheory.

> ... At this
> point it seems that entities resembles "classes" after all, and that classes
> have instances. Fine. In ASN we have that the nature of entity records are
> described in terms of attributes. So it seems to me that it should be possible
> to express the logical condition "x in instances(a) => x in instances(b)" in
> terms of relationships amongst attributes of a and b and their values? I know
> this is more of a OO approach than a DL approach.
>
> If we take out validity intervals and also attributes, we are left with nothing
> to connect the logical definition of viewOf with necessary conditions that can
> be expressed / enforced in the language.
>
> In summary, I am making all the cosmetic changes you suggest, but I would really
> like to make sure we address this last point.

I think that all I say above is by way of explaining why I am otherwise OK with 
the language you proposed [1] - by simply asserting that viewOf is transitive, 
it matches our intuitions whether or not they depend on intervals or instances 
or something else.  (The only risk here that I see from this approach is that we 
may later find that it does not match some other intuition we have not yet 
surfaced; in the scheme of things, I think that's a small risk compared with the 
risk of building on a lower-level model that not everyone understands or agrees 
with.)

#g
--

[1] 
http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-complement-of


> ps I really like the workflow example! It is one that Yolanda, amongst others,
> may find very familiar.
>
> --Paolo
>
>
>
>>
>> <aside>
>> I did, however finally come up with a practical example for "viewOf" that is not
>> based on time intervals. It comes from representations of workflows.
>>
>> Suppose one has a workflow template that may specify some resources to be used,
>> but leaves others open to specification (inputs, parameters, etc.). Then
>> suppose one derives a new workflow that uses the original but specifies some of
>> the previously unspecified inputs. (In functional programming terms, this would
>> be like partial function application.) One might claim that, for provenance
>> purposes, the more specific workflow is a viewOf the original workflow.
>> </aside>
>>
>> The remaining question, then, would be whether or not we want to formalize the
>> relationship between viewOf and [foobar] as I have suggested, by defining
>> [foobar] in terms of viewOf?
>>
>> I think that any further formalization of viewOf (and the rest) can be dealt
>> with in James' semantics document. I think that's also what you are suggesting
>> in your reference to a model theoretic interpretation?
>>
>> #g
>> --
>>
>>
>> On 15/12/2011 18:49, Paolo Missier wrote:
>>> 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
>>>
>
>

Received on Sunday, 18 December 2011 14:39:19 UTC