RE: [paq] using anchor or different links

| 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

Received on Thursday, 11 August 2011 21:54:38 UTC