Re: updates to PAQ doc for discussion

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"

By my understanding the original IVPof was not symmetrical.

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.

#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 18:12:25 UTC