Re: updates to PAQ doc for discussion

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.

>> 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 Friday, 19 August 2011 20:18:54 UTC