Re: [paq] using anchor or different links

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
>
> | 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.
>
> 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."
>
> 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.
>
> 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
>
>

-- 
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 Friday, 12 August 2011 06:16:27 UTC