- From: Myers, Jim <MYERSJ4@rpi.edu>
- Date: Fri, 19 Aug 2011 12:48:51 +0000
- To: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- CC: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>, Paul Groth <p.t.groth@vu.nl>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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 12:49:53 UTC