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

Paolo,

Broadly this looks good to me, but I think you may have copied my typo:

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

should rather be

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

(I.e. there exists some x such that both a and b are a view of that x.)

...

Also, a comment, but I don't think it impacts the proposal:

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

The problem I see is deciding what constitutes a "real world thing", and the 
/possibility/ that we have viewOf(a, b) where both a and b might be considered 
to be real world things.

If we don't need to refer (formally) to real world things, which I think the 
current proposal does not, then this is just a rhetorical device to explain the 
intuition and we don't need to be further concerned about the detail here.

#g
--


On 20/12/2011 10:01, Paolo Missier wrote:
> 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 Wednesday, 21 December 2011 15:12:24 UTC