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

Graham
   delayed response again -- sorry I live in proposal-land these days.

I have no objections. let me try to sum this up.
Are we happy to have:

viewOf: transitive -
viewOf: anti-symmetric and reflexive

foobar: symmetric -

the construction is as follows:
- these properties are by definition
- we provide an interpretation (a semantics) for viewOf, define foobar in terms of viewOf, and then show that the properties we associate to the relations are consistent with the interpretation.

I am happy for the semantics of viewOf to be based on instances, i.e.

viewOf(a, b) == forall(x) : x in instances(a) =>  x in instances(b)

foobar(a, b) == exists(x) : viewOf(x, a) and viewOf(x, b)

This avoids  "validity intervals" altogether, but I would rather shift the discussion to the semantics thread, as in the current draft  http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman the lifetime(e) of an entity e is clearly defined in terms of time intervals.

The fundamental assumption that an entity represents /exactly one/ 'real world thing' seems to be built into the current semantics already, and I would be surprised if it weren't, so I see no problem.

I am also proposing that we use the abstract/concrete workflow example in addition to Bob's simple example in sec. 5.3.3.3.

But before I make any further edits, we need to agree on these definitions.

For the time being, with reference to this other comment:
>>> "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.

I have used "val(e)" as a placeholder for "validity interval", and I see that James uses lifetime(e). Maybe this can be the temporary replacement for val(e)?

atb -Paolo






On 12/18/11 2:37 PM, Graham Klyne wrote:
> 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

Received on Tuesday, 20 December 2011 10:13:42 UTC