Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

[Juha Hakala <[e-mail]>]

Hello,

On 2.5.2014 20:16, John C Klensin wrote:
> (apps-discuss list dropped)
>
> Juha,
>
> I found this (both the part quoted below and the rest of your
> note) very helpful.  Thanks.  One question below...
>
> --On Friday, May 02, 2014 18:06 +0300 [e-mail]
> wrote:
>
> I would assume that, if the poem is published as part of a
> collection, the collection appears in a book, and the book is
> identified with an ISBN, the mechanism for finding the poem
> within the book becomes part of a specification about the book
> and its identifier.
Sort of. I left out some details from my description, but add them here 
because similar techniques are being put into use not only in libraries 
but in other organizations as well.

In our slang, there is a host record describing the book, and component 
part records describing the poem, article, image or any other thing in 
the book. There is a bidirectional link between host and component part 
records. Similar linking techniques are in use when libraries describe 
for instance serials and serial articles and CDs & tracks in them. The 
work level record of a poem, track, article or any other component part 
will be linked directly to the the component part record. Persistent 
identifiers are required in all levels, and there can be several of them 
- for instance, a periodical articles often have embedded images.

These component parts are sometimes components only in logical sense. 
Each track or article may be available as a separate file. But if a file 
contains many component resources, the file syntax may reveal this 
internal structure. For instance, when the National Library of Finland 
digitizes serials we often create structured METS/ALTO XML files where 
encoding shows the logical structure of the issue.
> That is an instruction about the component
> of the book, not what I think would normally be considered
> "metadata about the book".  And depending on other conventions
> or protocols (in the traditional, not computer sense), that
> mechanism might be shown as "page 57ff", "Chapter 5", or
> something else.   Some introducing (or surrounding) syntax would
> be needed for that sort of mechanism description and one would
> probably want it to be different from the mechanisms used to
> query, or extract information from, the "metadata about the
> book".

METS/ALTO encoding commonly used for digitized textual resources can do 
a lot. Not only can we encode articles, but also chapters, pages, 
paragraphs etc.; it is also possible to describe the font and size of 
each OCR'd character - and provide the probability of the correctness of 
the OCR result for each character.
>   
>
> While the distinctions are real, the details may be a matter of
> convention.  For example, if the book's table of contents were
> considered metadata about the book, the poem might also be found
> within the book by asking a question of that metadata and then
> using the result.
Table of contents (and abstract) is often provided as metadata for 
non-fiction books. So it is possible to find for instance an article 
within a book even if there is no separate metadata record for it. 
Whether it is possible to provide a direct link to such article depends 
on the encoding of the (text) file. Rich encoding takes time, but serves 
the users well.

>
> Is that just about right?  If not, where am I confused?

I don't think you are  ;-).

  Juha
>
> thanks,
>      john
>