Re: updates to PAQ doc for discussion

Graham,

I wasn't thinking of Sparql, rather I was more referring to the 
definitions. To me IVPof impose an additional constraint compared with 
complement of, and therefore, is less general.

Khalid

On 19/08/2011 12:22, Graham Klyne wrote:
> 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:26:49 UTC