Re: mini issue-57 doc feedback - p2

On Wed, Mar 23, 2011 at 10:30 PM, Nathan <nathan@webr3.org> wrote:
> Nathan wrote:
>>
>> Working from the "/latest" on 24th March
>
> first note, I think the term "Information Resource" is important to keep, it
> sets a context and gives people something useful to latch on to when
> reading.
>
> 1.2 Glossary
> as previously, consider "fixed" instead of generic, so:
> [
> accessible via
> When a URI is dereferenceable, "the information resource accessible via a
> URI" (abbreviated IR(that URI), see below) is the information resource whose
> versions are the versions obtained by dereferencing that URI. If there is
> only one such version, then it is a "fixed information resource".
> ]

I just removed the last sentence.

> I quite like the term "characterize" at the minute, consider (only a mild
> suggestion, I also like the text you wrote):
> [
> definition
> A document or document part that provides information about the meaning of a
> URI or other phrase. This term is not meant to be either rigorous or
> exclusive. The "information" could be prose, RDF, OWL, or some combination.
> It needn't be either complete or specific in "defining" the phrase, rather
> it's just supposed to characterize the referent of that phrase.
> ]

I'm tending in the direction of "meaning" instead of "referent"
because it is broader. I would say, for example, that rdf:type and
<about:blank> clearly "mean" but they do not obviously "refer". But I
don't feel too strongly about this.  (I would like to know what Pat
thinks...)

I know some people are bothered because they pretend not to know the
meaning of "meaning", but I think this is sort of like claiming not to
know what "is" means. I would answer: Tell me how what I've said might
be misinterpreted, how one could go wrong in applying what I've said
as a result of my using a word such as "mean". The same goes for
"refer" and "true".

> dereferenceable definition has minor typo ("a standard access mechanisms"),
> either change to "a standard access mechanism" or "standard access
> mechanisms" ?

 ok

> as previously, remove generic and swap specific for fixed, perhaps reword as
> (?):
> [
> information resource
> An "information resource" is either /fixed/, i.e. a document or other
> replicable entity such as an image or sound recording possessing a single
> version, or it is associated with multiple versions that have something in
> common. Metadata that is true of every version of an information resource is
> considered to be true of the information resource itself.
> ]

done

> phrase - would this not include literals too? (thinking it's synonymous with
> names in rdf-mt) - probably doesn't matter for this document though!

I suppose if you want to refer to (or mean) 17, you can just say 17.

> version, you've already defined this slightly differently higher up the
> document, consider re-writing to:
> [
> version
> Fixed content (octet sequence) together with directives, such as media type
> and language, intended to guide the interpretation of the content.
> ]

done

> WS(u), it appears to me that there's some URI mix up in here - perhaps it
> should read:
> [
> WS(u)
> WS(u) is shorthand for the meaning of a URI u according to the definition of
> u in (a version of) the information resource IR(u). For example, if
> IR('http://example/fred') says that 'http://example/image23' refers to Fred
> the mynah, then WS('http://example/image23') is Fred the mynah. ('WS' stands
> for 'whatever it says'.)
> ]

changed all to 'fred' ... don't know how that happened

> Section 2:
> Generally, it might be nice to <em> each name/phrase, for example
> "spoonwings" and "http://example/spoonwing", and also refer to the phrase
> again later so that "using the chosen phrase as the subject" would read
> "using the chosen phrase "http://example/spoonwing" as the subject".

em-ing is tantamount to quotation, and it's important that these
name/phrases not be quoted.  The report in question really *does* talk
about spoonwings, it doesn't just use the *word* "spoonwing" (in fact
it might use the neolatin Nemoptera instead; it doesn't matter for the
example).

> note sure I get the spoonwing variant use case "Variant use case: Same as
> above, but Bob's bibliography includes a number of RDF documents, and his
> metadata includes information relevant for making use of those RDF
> documents." - can it be explained a little more or removed?

I may flush all the variants. There are better ways to make the point.
This is just meant to be a case where Ian's architecture fails.

> general: perhaps hyperlink each instance of a term in the doc to it's
> definition (for example "phrase")?

what a royal pain.  I'll think about it.

> general: niggling over 2.3 .. it's the problem use case for sure, will come
> back to it later..

I have no sense of how important it is. Larry thinks it is in his tdb:
scheme draft, but it's not part of Harry's story and I don't know
whether it occurs in the wild.

> 3.1 URI scheme and URN namespace registrations:
> needs a specific real world example so people can grok it properly (at least
> so I can!)

mount:everest  or something... will work on it

> 3.2 The LSID URN namespace:
> Worth keeping if one can expand on what the URI for the IR is perhaps, it
> seems related but perhaps needs more info..

Right.  According to the spec, the LSID "identifies" an IR if the
content-length is positive, otherwise it "identifies" something else,
as described (one hopes) in the metadata. (so you can't have an LSID
"identifying" a zero-length IR!) I doubt this is respected in the wild
though. Will elaborate.

> 3.3 A dereferenceable URI refers to the information resource at that URI
> s/pubish/publish

Thanks!  Looking forward to more.

I'm still thinking about
- the title
- the overall pitch
- disposition of 3.3, which isn't like the other 3.n sections - maybe
move it to section 1

You may notice that I added a section 5.7 'no interoperability' -
David made a good point that the purpose of doing all this
coordination needs to be spelled out more clearly, so this was
supposed to say what happens if there is no agreement.

Generally I'm thinking about how to give the whole report more punch.
It's not *just* how to provide and discover URI definitions; it's how
to do so without also losing the ability to refer to IRs.

Jonathan

Received on Thursday, 24 March 2011 19:22:12 UTC