Re: updates to PAQ doc for discussion

Khalid,

I think my exchange with Jim has showed up that we're looking at different 
situations.  I think there's no single correct answer here, just figuring our 
what we actually want to do with these ideas.  I'm contemplating a further 
response to Jim when I get time to think it through more.

#g
--


Khalid Belhajjame wrote:
> 
> 
> Answer interleaved.
> 
> On 19/08/2011 21:07, Graham Klyne wrote:
>> Myers, Jim wrote:
>>>> Jim,
>>>>
>>>> In:
>>>> http://dvcs.w3.org/hg/prov/raw-
>>>> file/default/model/ProvenanceModel.html#concept-IVP-of
>>>> (I note the section anchor still retains the old name :)
>>>>
>>>> I see:
>>>> "we say that A is-complement-of B, and B is-complement-of A, in a
>>>> symmetrical fashion"
>>>
>>> But the next section says asymmetric is OK too...
>>>
>>>> By my understanding the original IVPof was not symmetrical.
>>>
>>> I would use the open world to claim it was - the existence of some 
>>> properties where A is more immutable than B doesn't stop the opposite 
>>> from being true as well...
>>
>> I think that depends on how they are derived.  My working assumption 
>> has been that one has a dynamic resource, but to meaningfully express 
>> provenance about that resource one has to adopt a constrained view.
>>
>> For example, a W3C specification undergoes a number of revisions, but 
>> they are all identified with the same latest-version link. This 
>> suggests the specification though its lifetime as a dynamic resource, 
>> and particular revisions as constrained views of that resource.  
>> Provenance might be applied to either; e.g. if the creator of the 
>> overall resource is Tom, then Tom is also the creator of the various 
>> revisions, but the most-recent editor is static only for given revisions.
>>
>> This kind of constraining relation seems useful and natural to me - 
>> even in an open world - and reasonably easy to reason about to boot.  
>> But I can't see what useful actionable purpose is served by a 
>> relationship like complementOf.  For me, the complexity and 
>> impenetrability of the description is inicative of a problem here.
> 
> I would actually argue the opposite :-)
> Given an entity that is being characterized by two observers, the two 
> characetrizations  that we end up with are likely to be complementary, 
> in the sense that one of them include immutable properties that are 
> mutable (or not at all) described by the second characterization, and 
> vice-versa.
> 
> Khalid
> 
>>
>>>> In the example given there, I think it is claiming that, say, views 
>>>> M3 and L2 are
>>>> complementOf, but I'd say they are not in any IVPof relation.
>>>
>>> I would have said IVPof fits this too, but I'm not sure that opinion 
>>> was shared. I think the broader, potentially symmetric definition is 
>>> what we need, 
>> regardless of what the answer was.
>>
>> Interesting - almost the opposite of what I just wrote :)
>>
>> What (practical) *use* do you see in the complementOf relation?  Why 
>> might a developer of provenance-handling software care about it?
>>
>> Cheers,
>>
>> #g
>> -- 
>>
>>
>>>> Myers, Jim wrote:
>>>>> I hadn't interpreted the name change and lifting of the property
>>>> restrictions as changing the definition as you do it below. Is that 
>>>> what is being
>>>> proposed? To limit complementOf to ~peer relations versus simply 
>>>> being a
>>>> drop-in replacement for IVPof with less definition of how properties 
>>>> might
>>>> relate?
>>>>>  Jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Graham Klyne [mailto:Graham.Klyne@zoo.ox.ac.uk]
>>>>>> Sent: Friday, August 19, 2011 7:22 AM
>>>>>> To: Myers, Jim
>>>>>> Cc: Khalid Belhajjame; Paul Groth; public-prov-wg@w3.org
>>>>>> Subject: Re: updates to PAQ doc for discussion
>>>>>>
>>>>>> I too find the name unhelpful.  But I'm also concerned about the form
>>>>>> of the definition.  I'm not sure "generality" is the right aspect,
>>>>>> though, as in some ways I see IVPof (to use the old name) as being
>>>>>> more general than complementOf.
>>>>>>
>>>>>> Why:
>>>>>>
>>>>>> Roughly, using SPARQL, I can use IVPof to locate instances of
>>>> complementOf.
>>>>>> But I can't see how to do the other way.
>>>>>>
>>>>>> e.g.
>>>>>>
>>>>>> [[
>>>>>> CONSTRUCT
>>>>>>     { ?v1 complementOf ?v2 }
>>>>>> WHERE
>>>>>>     { ?v1 IVPof ?r ; ?v2 IVPof ?r }
>>>>>> ]]
>>>>>>
>>>>>> So from this operational perspective, IVPof is more generally 
>>>>>> applicable.
>>>>>>
>>>>>> (But from another perspective, this is possible because IVPof is more
>>>>>> constraining - less general - that complementOf.  Hence my comment
>>>>>> about generality not necessarily being a helpful criterion.)
>>>>>>
>>>>>> I find that when I think about provenance being related to an
>>>>>> invariant or less variant view of a resource (e.g. see the discussion
>>>>>> at
>>>>>> http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-
>>>>>> access.html#provenance--context-and-resources),
>>>>>> the notion of IVP is useful.  I have not yet found a case where
>>>>>> talking/thinking about complementOf is useful to me.  Fior this
>>>>>> reason, I prefer having IVPof (or viewOf, or some other name) to
>>>> complementOf.
>>>>>> #g
>>>>>> -- 
>>>>>>
>>>>>>
>>>>>> Myers, Jim wrote:
>>>>>>> I'm complaining about the name 'complement' not the generality of
>>>>>>> the definition. Complementary angles are not different
>>>>>>> characterizations of the same angle, they are different angles that
>>>>>>> create a whole. A wine complements food. Some other term with the
>>>>>>> broader definition would be fine. (BTW: I am beginning to think that
>>>>>>> being able to associate a time interval with the relationship would
>>>>>>> be useful...)
>>>>>>>
>>>>>>>  Jim
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Khalid Belhajjame [mailto:Khalid.Belhajjame@cs.man.ac.uk]
>>>>>>>> Sent: Wednesday, August 17, 2011 1:31 PM
>>>>>>>> To: Myers, Jim
>>>>>>>> Cc: Paul Groth; Graham Klyne; public-prov-wg@w3.org
>>>>>>>> Subject: Re: updates to PAQ doc for discussion
>>>>>>>>
>>>>>>>> Hi Jim
>>>>>>>>
>>>>>>>> On 16/08/2011 13:45, Myers, Jim wrote:
>>>>>>>>> As for complementOf - since complement means 'counterpart' and
>>>> has
>>>>>>>>> the
>>>>>>>> notion of not being the same thing - being separate and adding to
>>>>>>>> the thing, I don't think it works as a replacement for IVPof -
>>>>>>>> viewOf doesn't capture everything but would be better than
>>>>>>>> complement in that its English meaning does not conflict ...
>>>>>>>>
>>>>>>>> I am not sure I understand what you mean. Could you please
>>>> elaborate?
>>>>>>>> The way is complement of is defined seems to me more general that
>>>>>>>> IVP of and also more natural. While IVPof requires that all the
>>>>>>>> immutable attributes of one characterization are subset of the
>>>>>>>> immutable attributes of the other characterization, isComplementOf
>>>>>>>> does not pose this constraint, which is
>>>>>>>> plausible: in practice, when we have two characterizations of an
>>>>>>>> entity, these characterizations are likely to use different set of
>>>>>>>> attributes depending on the observer, and the likelihood that the
>>>>>>>> immutable attributes of one are subset of the immutable attributes
>>>>>>>> of the
>>>>>> second is small.
>>>>>>>> Khalid
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>   Jim
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Paul Groth [mailto:p.t.groth@vu.nl]
>>>>>>>>>> Sent: Tuesday, August 16, 2011 1:21 AM
>>>>>>>>>> To: Myers, Jim
>>>>>>>>>> Cc: Graham Klyne; public-prov-wg@w3.org
>>>>>>>>>> Subject: Re: updates to PAQ doc for discussion
>>>>>>>>>>
>>>>>>>>>> Hi Jim
>>>>>>>>>>
>>>>>>>>>> I think<link>  elements in PAQ serve a different purpose the
>>>>>>>>>> semantics is here's how you find me (the resource)  in provenance
>>>>>>>> information.
>>>>>>>>>> ComplementOf has a much more constrained meaning.
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Aug 16, 2011, at 3:01, "Myers, Jim"<MYERSJ4@rpi.edu>  wrote:
>>>>>>>>>>
>>>>>>>>>>> But, having introduced the definition in this way, other uses
>>>>>>>>>>> are possible.  The example I've started thinking about is that
>>>>>>>>>>> multiple <link>  elements might indicate different URIs denoting
>>>>>>>>>>> different levels of
>>>>>>>>>> invariance.
>>>>>>>>>>> - why aren't these just IVPof relationships? (I'm not arguing
>>>>>>>>>>> against encoding pil relationships as links, just against 
>>>>>>>>>>> adding a
>>>> 'target'
>>>>>>>>>>> concept that duplicates other relationships in the model.)
>>>>>>>>>>>
>>>>>>>>>>> Jim
>>>>>>>>>>> ________________________________________
>>>>>>>>>>> From: Graham Klyne [graham.klyne@zoo.ox.ac.uk]
>>>>>>>>>>> Sent: Monday, August 15, 2011 5:38 PM
>>>>>>>>>>> To: Myers, Jim
>>>>>>>>>>> Cc: Paul Groth; public-prov-wg@w3.org
>>>>>>>>>>> Subject: Re: updates to PAQ doc for discussion
>>>>>>>>>>>
>>>>>>>>>>> Myers, Jim wrote:
>>>>>>>>>>>>> In Issue 46 (http://www.w3.org/2011/prov/track/issues/46), Luc
>>>>>>>>>>>>> raised the point that the scenario we had agreed to address
>>>>>>>>>>>>> included a case where the recipient of a resource
>>>>>>>>>>>>> representation had no way to know its URI for the purposes of
>>>>>>>>>>>>> provenance discovery.  After short discussion, my response to
>>>>>>>>>>>>> this issue was to introduce a new link relation type
>>>>>>>>>>>>> (currently called
>>>>>>>>>>>>> "target") to allow this URI to be encoded
>>>>>>>>>> in the header of an HTML document.
>>>>>>>>>>>>> Does this help?
>>>>>>>>>>>> So this is only used inside an HTML entity?
>>>>>>>>>>> That was the compelling use-case, but once defined, other uses
>>>>>>>>>>> are not
>>>>>>>>>> excluded.
>>>>>>>>>>>> ... I.e. it is not a relationship between two entities, but is
>>>>>>>>>>>> a means to embed an identifier in an entity (for HTML)?
>>>>>>>>>>> Interesting take.  Practically, in the HTML use case, I think
>>>>>>>>>>> I'd have to
>>>>>>>> agree.
>>>>>>>>>>> But I think it is still technically a relation in the same way
>>>>>>>>>>> that owl:sameAs is a relation, even though its semantics tell us
>>>>>>>>>>> that the related RDF nodes denote the same thing.  Like all
>>>>>>>>>>> HTML<link> elements, it defines a relation between the resource
>>>>>>>>>>> of which the containing document is a representation and a
>>>>>>>>>>> resource denoted by the given
>>>>>>>>>> URI.  They may both be the same resource.
>>>>>>>>>>> But, having introduced the definition in this way, other uses
>>>>>>>>>>> are possible.  The example I've started thinking about is that
>>>>>>>>>>> multiple <link>  elements might indicate different URIs denoting
>>>>>>>>>>> different levels of invariance.  If the HTML is a document in a
>>>>>>>>>>> source code management system, one such URI might denote a
>>>>>>>>>>> specific version, and another might denote the "current"
>>>>>>>>>>> version, both of which might reasonably
>>>>>>>>>> be the referent for provenance assertions.
>>>>>>>>>>> These other uses are not reasons that the propoal was
>>>>>>>>>>> introduced, but are just consequences of not placing unnecessary
>>>>>>>>>>> constraints on the use of the existing<link>  feature as 
>>>>>>>>>>> defined.
>>>>>>>>>>>
>>>>>>>>>>>> An "ID card" mechanism that would allow me to keep my
>>>>>>>>>>>> rdf:resource URL
>>>>>>>>>> on my physical body so you could connect me to my online identity
>>>>>>>>>> is the same type of thing?
>>>>>>>>>>> Hmmm... I suppose you might think of it like that, but I'm wary
>>>>>>>>>>> of adopting that view as it tends to arbitrarily exclude other
>>>>>>>>>>> possibilities that arguably should flow from this use of
>>>>>>>>>>> the<link>
>>>>>> element.
>>>>>>>>>>> #g
>>>>>>>>>>> -- 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>

Received on Monday, 22 August 2011 09:48:51 UTC