Re: [paq] using anchor or different links

Paul,
Yogesh,


Paul Groth wrote:
> Hi Yogesh,
> 
> Thanks for the clarifications. If Graham is happy I think changing the 
> names seems appropriate.
> 
> Graham?
> 
> cheers,
> Paul
> 
> 
> Yogesh Simmhan wrote:
>> | Two things around the use of "anchor". One I would like all 
>> proposals to
>> | use the same terminology for consistency so could we use "anchor" in 
>> the
>> | html case?
>> The IETF spec uses the "anchor" parameter name [1] to refer to the 
>> Context IRI
>> [2]. So "Context URI" may be a better term for the purposes of 
>> description. The
>> "anchor" name itself can be used as the actual header/tag/attribute name.
>>
>> See www.w3.org/2011/prov/track/issues/74

I think I'm OK with "Context-URI" rather than "Target-URI", thougth there are 
some other issues I'd like to see settled before finally committing on this.

But I'm a bit confused by the references here to "The anchor name itself can be 
used as the actual header/tag/attribute name".  What we're actually proposing 
here is a new link relation type for use primarily in an HTML <Link> element.

>> | Also, is the "anchor" defined in the IETF spec what we mean?
>> |
>> The spec states: "By default, the context of a link conveyed in the 
>> Link header
>> field  is the IRI of the requested resource.
>> When present, the anchor parameter overrides this with another URI, 
>> such as a
>> fragment of this resource, or a third resource (i.e., when the anchor 
>> value is
>> an absolute URI)."
>>
>> My reading of this is that the relation (e.g. provenance) by default 
>> describes
>> the entire resource being accessed through HTTP. It is possible to 
>> have the
>> relationship describe either a subset of the current resource (this is
>> advantageous when we want to have different provenance to describe 
>> different
>> parts of the HTML file, though it is out of scope for the current 
>> scenario), and
>> in addition, used to describe an external resource (e.g. an image in 
>> the HTML
>> document). This seems to fit our description of target-uri.

These are additional possible uses for the target/context URI, IMO, but the 
compelling use case here was an HTML resource on a memory stick, for which no 
other URI is known.

>> There are two caveats in the spec that state
>> "Consuming implementations can choose to ignore links with an anchor
>> parameter.", and
>> "Link headers that use the "anchor" parameter to associate a link's 
>> context with
>> another resource should be treated with due caution."

Which spec is this?  Actually, I don't see those caveats as problems.  (a) may 
result in the consuming application failing to locate provenance information, 
which I regard as a "fail safe".  (b) In my view, the provenance information 
should be self-defining with respect to target/context URIs, so I think amn 
incorrect URI leads to a failure to find information rather than a wrong 
interpretation.  See also: PAQ security considerations.

>> However, the advantages of leveraging the existing anchor parameter 
>> for PAQ
>> would seem to outweigh these concerns, as opposed to introducing a new 
>> "target"
>> relationship.

I would agree, except that there is no equivalent for the HTML <link> element? 
which is the case for which we nost need a solution.  It's availability for use 
with HTTL link elements is, IMO, at most a side effect.

#g
--


>>
>> See www.w3.org/2011/prov/track/issues/73
>>
>> | If so that maybe a better term. As someone pointed out in the 
>> problem of
>> | overloading a name might also be the case for "target" as well.
>> |
>> Target IRI/URI [3] is used in the spec for a different purpose (what 
>> we call
>> provenance-uri). So we should avoid overloading its use.
>>
>> See www.w3.org/2011/prov/track/issues/74
>>
>>
>> --Yogesh
>>
>> [1] https://tools.ietf.org/html/rfc5988#section-5
>> [2] https://tools.ietf.org/html/rfc5988#section-5.2
>> [3] https://tools.ietf.org/html/rfc5988#section-5.1
>>
>>
>> | cheers,
>> | Paul
>> |
>> | Yogesh Simmhan wrote:
>> |>  Some comments on Sec 3,3.1. One question I have is why we're not 
>> using
>> | "anchor"
>> |>  instead of introducing the "target" relationship for the HTTP 
>> case. Using
>> anchor
>> |>  would allow provenance URI and the Target URI to be specified in a 
>> single
>> header
>> |>  and also disambiguate when multiple provenance URIs exist for 
>> different
>> Target
>> |>  URIs.
>> |>
>> |>  == Sec 3 ==
>> |>  *) "Once provenance information information is retrieved, one 
>> needs how to
>> |>  identify the view of that resource within that provenance 
>> information. This
>> view
>> |>  is known as the target and is identified by a Target-URI. "
>> |>  This line is vague since a view has not been defined. Also 
>> duplicate "
>> |>  information"?
>> |>
>> |>  *) "Finally, in section Not foundarbitrary-target, we discuss the 
>> case of a
>> |>  resource ... "
>> |>  Missing reference?
>> |>
>> |>
>> |>  == Sec 3.1 ==
>> |>
>> |>  *) "The same basic mechanism can be used for referencing provenance
>> | information"
>> |>
>> |>  Should we add "when accessing a Resource using HTTP" to refer to the
>> scenario
>> | we
>> |>  are discussing
>> |>
>> |>  *) "Link: provenance-URI; rel="provenance" Link: target-URI; 
>> rel="target" "
>> |>  Split into multiple lines? Else it seems to break the RFC 5988.
>> |>  If we have multiple provenance URIs, how do we know whuch target 
>> URI is
>> | present
>> |>  in which provenance URI?
>> |>
>> |>  *) "If no target link is provided then the target-URI is assumed 
>> to be the
>> URI
>> |>  of the resources."
>> |>  Is it resource*s* ?
>> |>
>> |>  *) Why can't we use the "anchor" parameter for the target URI? E.g.
>> |>  "Link: provenance-URI; rel="provenance"; anchor="target-URI"
>> |>
>> |>  *) "An HTTP response may include multiple provenance link headers,
>> indicating a
>> |>  number of different resources that are known to the responding 
>> server, each
>> |>  providing provenance about the accessed resource."
>> |>  Its is not clear if you mean that the "Resource" can have multiple
>> Provenance
>> |>  URIs that describe one or more Target URIs.
>> |>
>> |>  *) "...other publishers may offer provenance information about the 
>> same
>> |>  resource."
>> |>  Is this the Target resource we're talking about here?
>> |>
>> |>
>> |>  | -----Original Message-----
>> |>  | From: public-prov-wg-request@w3.org [mailto:public-prov-wg-
>> | request@w3.org]
>> |>  | On Behalf Of Paul Groth
>> |>  | Sent: Wednesday, August 10, 2011 12:38 PM
>> |>  | To: public-prov-wg@w3.org
>> |>  | Subject: updates to PAQ doc for discussion
>> |>  |
>> |>  | Hi All,
>> |>  |
>> |>  | Graham and I have been making some changes to the PAQ document 
>> [1] that
>> |>  | we would like to request feedback on at tomorrow's telecon.
>> |>  |
>> |>  | In particular, we have updated Sections 1 and 3. We've added a 
>> section
>> |>  | on core concepts and made section 3 reflect these concepts. We 
>> think
>> |>  | this may address PROV-ISSUE-46 [2].
>> |>  |
>> |>  | Please take a look and let us know what you think.
>> |>  |
>> |>  | Thanks,
>> |>  | Paul
>> |>  |
>> |>  | Note: Section 4 Provenance discovery service is still under 
>> heavy editing
>> |>  |
>> |>  |
>> |>  | [1] 
>> http://dvcs.w3.org/hg/prov/raw-file/default/paq/provenance-access.html
>> |>  | [2] http://www.w3.org/2011/prov/track/issues/46
>> |>
>> |>
>> |
>> | --
>> | Dr. Paul Groth (p.t.groth@vu.nl)
>> | http://www.few.vu.nl/~pgroth/
>> | Assistant Professor
>> | Knowledge Representation&  Reasoning Group
>> | Artificial Intelligence Section
>> | Department of Computer Science
>> | VU University Amsterdam
>>
>>
>

Received on Monday, 15 August 2011 14:42:53 UTC