Re: updates to PAQ doc for discussion

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 08:33:42 UTC