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"

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...

> 
> 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.

Thanks,
 Jim


> 
> #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 19:09:38 UTC