- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Tue, 23 Aug 2011 09:09:41 +0100
- To: public-prov-wg@w3.org
Hi Olaf,
Thanks for copying and pasting relevant excerpts from previous emails.
Some questions/comments interleaved.
On 08/23/2011 07:23 AM, Olaf Hartig wrote:
> Hello Luc,
>
> On Tuesday 23 August 2011 00:50:36 Provenance Working Group Issue Tracker
> wrote:
>
>> PROV-ISSUE-78 (contexts-and-provenance-uris): multiple contexts and
>> provenance-uris [Accessing and Querying Provenance]
>>
>> http://www.w3.org/2011/prov/track/issues/78
>>
>> Raised by: Luc Moreau
>> On product: Accessing and Querying Provenance
>>
>>
>> We seem to allow for multiple context-uris and provenance-uris to be
>> provided. I am fine with this.
>>
>> But don't we want to be able to say, for instance:
>>
>> context-uri1 provenance-uri1
>> context-uri1 provenance-uri2
>> context-uri2 provenance-uri3
>> context-uri2 provenance-uri4
>>
>> Do we want to be able to express this?
>>
> I would like to see that, where possible.
>
Great.
Of course, there is a question that follows. What can a client usefully
do with this information? Having these uris is a bit terse, and in the
absence of metadata, it seems that the client is only left with the choice
of dereferencing all these provenance-uris.
In that case, is it really worth being precise about the "mapping"
context-uri -> provenance-uri?
It seems that:
{context-uri1, context-uri2}
and
{provenance-uri1,provenance-uri2,provenance-uri3,provenance-uri4}
could have just done the job as well.
Alternatively, an encoding that allows for, e.g.,
context-uri1 provenance-uri1 (prop1=val1, prop2=a)
context-uri1 provenance-uri2 (prop1=val2, prop2=a)
context-uri2 provenance-uri3 (prop1=val1, prop2=c)
context-uri2 provenance-uri4 (prop1=val2, prop2=c)
is then becoming useful, since a client can decide between
context-uri1/2 (according to prop2)
and between provenance-uri1/2 (according to prop1). Thus it can
selectively dereference a single
of the provenance-uris.
Is there a way of embedding such metadata?
>
>> Can this be expressed?
>>
> It depends. You have to distinguish two cases here: 1.) the HTTP Link header
> field (Sec.3.1 in the PAQ document) and 2.) the HTML link element (Sec.3.2).
>
> We are currently discussing this [1,2].
>
> The situation is as follows: For the HTTP Link based mechanism we have the
> anchor parameter with which it is possible explicitly associate a context-URI
> with a provenance-URI. For the HTML link based mechanism there is nothing
> equivalent. That's why Section 3.2 introduces an "anchor" (name is subject to
> discussion) link relation type (in addition to the "provenance" link relation
> type). Primarily for consistency (as far as I understand) an equivalent link
> relation type "anchor" has been introduced in Sec.3.1 for the HTTP Link based
> mechanism. The discussion here is (see the first Issue in Sec.3.1) whether we
> use that additional "anchor" link relation type for the HTTP case (which would
> not allow us to express what you ask for) or if we use the anchor parameter
> instead (which would allow us to express what you ask for). In what follows,
> I copy the relevant parts of the corresponding email discussions.
>
> Olaf Hartig wrote [1]:
>
>> Graham wrote:
>>
>>> Olaf Hartig wrote:
>>>
>>>> [...]
>>>> *) Regarding the first Issue (i.e. a separate Link header field for
>>>> anchor or anchor as a parameter): We should pick the second because it
>>>> is precise about which provenance-URI is associated with which
>>>> context-URI.
>>>>
>>> That is true. But that [precision cannot be achieved using the
>>> alternative mechanisms. especially HTML<link> element, so I'm actually
>>> leaning the other way.
>>>
>> I would consider HTTP Link header fields more important than HTML link
>> elements because they serve a more general use case. In other words, we
>> shouldn't introduce an unnecessary limitation in the preciseness of the
>> HTTP Link based mechanism that we propose, only because the (more
>> specific) HTML link based mechanism isn't expressive enough.
>>
>
I agree with you, Olaf, the HTTP Link header option works with all
formats, not
just html. So,it's a general mechanism.
> Graham Klyne wrote [2]:
>
>> Yogesh Simmhan wrote:
>>
>>> [...]
>>> Graham:
>>> | Yogesh:
>>> |> [...]
>>> |> *) "An HTTP response may include multiple provenance link headers...
>>> |> Likewise, an HTTP response may include... "
>>> |> - Besides the above issue of the provenance being related to the
>>> |> resource being accessed (rather than the context-uri), I would like
>>> |> some clarity on what the multiple "anchor" mean. I would expect when
>>> |> multiple provenance-URIs and context-URIs are returned through
>>> |> multiple "Link:" headers, then one or all the provenance-URIs *may*
>>> |> describe one or all the context-URIs. It is upto the accessor to
>>> |> access each of the provenance-URIs to determine which of them describe
>>> |> which context-URIs. If this is indeed the intention, can it be made
>>> |> clearer? Also, it is not clear what resource you mean by "the resource
>>> |> may": the provenance resource or the resource being accessed by the
>>> |> HTTP GET/HEAD?
>>> |
>>> | Yes, this is a point that needs clarifying. It is also a (small)
>>> | difference between using "Link anchor=..." vs two separate link
>>> | headers.
>>>
>>> Yes, that is true.
>>>
>> From thinking about Olaf's comments, I'm starting to think the "anchor"
>> and provenance context-URI might be subtly different. Still thinking.
>>
>
Can't we consider adding a new attribute to the Link element in html?
Does the schema
allows for that?
> Cheers,
> Olaf
>
> [1] http://lists.w3.org/Archives/Public/public-prov-wg/2011Aug/0256.html
> [2] http://lists.w3.org/Archives/Public/public-prov-wg/2011Aug/0253.html
>
>
Cheers,
Luc
--
Professor Luc Moreau
Electronics and Computer Science tel: +44 23 8059 4487
University of Southampton fax: +44 23 8059 2865
Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk
United Kingdom http://www.ecs.soton.ac.uk/~lavm
Received on Tuesday, 23 August 2011 08:10:21 UTC