Re: mini issue-57 doc feedback

On Wed, Mar 23, 2011 at 9:43 PM, Nathan <nathan@webr3.org> wrote:
> Working from the "/latest" on 24th March
>
> 1.1 Information Resources
> I'm not sure about the "generic" terminology, I feel it may be better to
> invert and define a "fixed" information resource instead and drop any
> mention of representation, so the 2nd and 3rd paragraphs could be changed
> to:
>
> [[
> Each information resource has one or more associated versions, each having
> fixed content (octet sequence) and interpretation directives (media type,
> language). An information resource having only one version is said to be
> /fixed/. No particular meaning is implied by the word "version" the word is
> chosen as suggestive of its most common use.
>
> One can apply metadata properties such as author, title, and topic to
> versions in the obvious way. These properties extend to information
> resources in a systematic way, as follows: if a property is shared by all of
> an information resource's versions, then we say that the information
> resource possesses the property, and vice versa.
> ]]

Done.

I know someone is going to take me to task for this "version"
business. I really wish I could convince TimBL to drop the idea that
the meaning of a resource is part of the resource - that there is
"phlogiston" that can distinguish two fixed IRs that share the same
version. I think it's not a very good theory of provenance. If we
could dispense with "phlogiston" then fixed resources and
versions/representations collapse to the same thing and the theory
becomes much more transparent. (The distinction in my opinion is
reflected in our knowledge state, not in the entities themselves, so
insisting on phlogiston is a kind of use/mention confusion.) But I'm
not going to count on talking him out of it, given how difficult it is
to engage him and how much we need his support.

> Question:
> How do you write metadata about a single version?
>
> Personal gut answer:
> Each IR(u1) is associated with a non empty set of versions SV. For any v in
> SV, if content-location(v u2) and u2 is not equal to u1, then v is
> associated with IR(u1) and IR(u2). If v is the only version in SV associated
> with IR(u2) then IR(u2) is a fixed information resource and v is it's only
> reading.
>
> Works for me, also means that the following ir-axiom is vital (I've changed
> "readings" to "versions"):
> "Let P be a metadata property, let R be an 'information resource', and let x
> be a member of the range of P. Then P(R,x) if and only if P(S,x) holds for
> all versions S of R."
>
> .. and obviously means that content-location would need to be a metadata
> property (as http etc already defines it to be), and also means that the 'ol
> "Content-Location instead of 303" proposal that IanD suggested last year
> means trading off the ability to speak of "versions" (and directly goes
> against the http specification the reason content location is there).

Content-location is a strong hint that the target is a fixed
"subresource" of the original IR, but I would be wary of trusting it;
and also the header is often not supplied at all.

I think it would be better to be more explicit. Say that the version
you're talking about was fetched using a particular URI at a
particular time, and that it has a particular etag or SHA1. Or,
provide the HTTP headers that were used by the server in selecting the
version (accept-language, cookies, etc.). Better, use data: ; or put a
copy of it somewhere and let someone fetch it from there. Or do all of
the above...

anyhow, this isn't our problem right now, thank goodness.

Thanks for the suggestions.

Received on Thursday, 24 March 2011 16:38:19 UTC