- From: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- Date: Fri, 19 Aug 2011 12:22:24 +0100
- To: "Myers, Jim" <MYERSJ4@rpi.edu>
- 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 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