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 11:23:18 UTC