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
| 
| 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.
|
Since the IETF Web Linking spec provides HTTP with context-uri's that use the
"anchor" parameter to perform the same job as the "target" relation we
introduce, the suggestion was to use the built in context-uri feature for
documents retrieved using HTTP instead of introducing a new HTTP Web Link
relation.

An equivalent parameter does not exist in the HTML Link element. So we will need
to introduce a new relation in HTML as is being done in the PAQ (currently
called the target). The comment was concerning what we call this relationship.
In order to strive for consistency across HTTP Web Linking and HTML Link
element, we may consider using "anchor" or "context " as the relationship name
in HTML, rather than "target".

However, it is true that we may end up conflating a HTTP parameter (anchor) with
a HTML relationship (anchor/context-uri) by introducing the relation only in
HTML and reusing a parameter in HTTP. So one may argue that the new relation
must also be introduced in HTTP to be consistent. I was looking at making the
least set of changes and keeping names/concepts consistent even through these
changes.

| >> | 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.
| 
I agree we need the concept of target/context URI present in the HTML document
and also that the Link element is the most suitable. This is a question of what
we call the relation and if we should keep it consistent with HTTP Web Linking.


| >> 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.
|
These caveats were in the HTTP web Linking spec
(https://tools.ietf.org/html/rfc5988#section-5.2, Page 7) and
(https://tools.ietf.org/html/rfc5988#section-7, Page 17). I am comfortable with
these too and don't see them as an issue.
 
| >> 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.
| 
I agree to the first part that we need a relation for HTML. However, since we're
addressing 3 cases where we deal with HTTP-accessed, HTML and RDF documents (in
Sec 3), it seems we should consider reusing an existing HTTP parameter that may
fit our needs. Our problem arises since the HTTP Web Linking and HTML Link
element are not fully consistent. So reusing anchor will break compatibility
with having the same relations in HTTP and HTML, while introducing
target/context in both will end up ignoring an existing parameter that is the
equivalent. 

Maybe one approach is to state that in the HTTP case, the "context" relation we
introduce has the same meaning as the "anchor" parameter and they *should* be
the same? Or otherwise state that the "anchor" parameter *must* be ignored for
the "provenance" relation in HTTP?

--Yogesh

| #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 15:18:09 UTC