Re: updates to PAQ doc for discussion

[Replying primarily to Jim's comment here]

The purpose of the link elements/headers is to provide information that can be 
used to locate the appropriate provenance information, not to express the actual 
semantics of the relation.  This is what I was asked to provide functionality 
for.  I certainly don't see them *replacing* information that should properly be 
encoded in the provenance information.

#g
--

On 23/08/2011 11:32, Luc Moreau wrote:
> Hi Jim,
>
> This is spot on.
>
> It is related to what I was saying to Olaf this morning [1]
> (though I was only talking about pil:Entity, and not IVPof. And it's something
> that would be useful to make explicit.)
> We are in the process of encoding model concepts in html/http.
> I have nothing against it, in fact, I welcome it, but it should be clear
> to everybody that it is what we do!
>
> Cheers,
> Luc
>
>
> [1] http://lists.w3.org/Archives/Public/public-prov-wg/2011Aug/0307.html
>
>
>
>
>
> On 08/16/2011 01:45 PM, Myers, Jim wrote:
>> It's the extension beyond that use I'm concerned about. If links can point to
>> "URIs denoting different levels of invariance" as Graham considers, it becomes
>> an alternate method of specifying IVPof relationships (I can point to three
>> targets and expect you to understand that those three are in IVPof
>> relationships and represent me (the resource) in different ways, or I can link
>> to one and use IVPof statements there to achieve the same goal. Why should we
>> allow a target link to have overlapping functionality with IVPof?). If we
>> really need to start putting additional provenance information in links (i.e.
>> telling you about more than one IVPof me), why not at least use pil terms =
>> 'rel = "IVPof" ' or whatever we settle on?
>>
>> 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 ...
>>
>> 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 Thursday, 25 August 2011 14:55:29 UTC