[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SUMMARY] issues under contention in debian metadata



On Thu, Jul 09, 1998 at 02:55:18AM -0400, Adam P. Harris wrote:
> 
> I'd like everyone to take a step back and relax. I'd like to thank
> everyone for participating, and the rest of the debian-doc list for
> onlooking.  Remember, we're all volunteers here for the fun of it.

<breath in><breath out><counting from 1 to 10> Feel better now, thank you ;)

> Identifiers composition:
> 
>   Marcus' straw man: Identifier is always absolute URL
>      con - FSSTD to FHS transition requires docreg edits
>      con - not really a serious proposal ?

It is not a serious proposal. It would solve all problems, but is
unnecessarily extreme, because I think the APH's URN proposal is clean and
doable. If no satisfactioon can be achieved by your or Marcos proposal, you
may want to drop the relative Identifier completely, which would lead to
my "sort-of-proposal". Let me say: Keep in mind that you don't need to
provide relative identifiers. KISS.

Although I personally favour the URN scheme, I would not abandon my
"sort-of-proposal" to soon. In the long run it is simple and easy to
understand, and I don't think changing the docreg file once is too much
hassle for the maintainer, who has to check all files for FHS comliance
anyway. Important: This could easily be made a lintian check!
 
>   APH's URN: Identifier is URL, or a URN of the form
>              'debian://package/<file relative to pkg doc area>'.
>      pro - FSSTD to FHS transition doesn't not require docreg change
>      pro - flexible URN2URL translation would allow use of central
>            document systems
>      pro - Identifier element is assured to be unique, at least within
>            the pkg, since it contains the package name

Yes, and because a package is not considered to contain different /usr/doc *and*
/usr/share/doc files with the same name.

>      con - requires a URN2URL processor of some sort, which would have
>            to gracefully cope with FSSTD->FHS

This would be done in install-docs, before the document registration starts,
when we have tools to access a database. As the discussion about the data
base is postponed, every program reading the docreg file has to cope with
it.

>      con - wordy (could we have an implied syntax that wouldn't
>            confuse people?)

We would probably end up with the implied syntax "package/<file>". This is
only confusing if the docreg file is also in the "/usr/doc" directory
(because one could assume that it is a path relative to the position of the
odcreg file). As long as it is pointed out that this will be relative to the doc
directory regardless the position of the docreg file, everything is clear.
 
> Identifier uniqueness:
>   Under debate.  I would propose the following: each metadata must
>   refer to one and only one resource (URL or URN).  However, a URN or
>   URN *may* have several metadata that refer to it.  Will this make
>   display systems and data shadowing complex?  Basically, metadata
>   identifiers would not have to be unique.

As long as the quadruple of required tags provide a unique set of data,a
one to one mapping can be achieved, and you can take this for tags as a
unique doc-id. I don't think it is very likely that two different packages
will ever provide a document with same idenitifier, Title, Format and
Subject data. If this happens, the rest of the data could be compared if it
is identical, too.

It is important to keep in mind here that those four tags will tell us
nothing about the relationship of two documents. Translations, format
conversions etc. have to be marked elsewhere.

Marcus

-- 
"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


--  
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: