Re: Re^12: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> Ok and then we#ve got the Relation tag. And for this tag we need an
> identifier. Right? And this identifier has to be unique in our "docreg
> system" and persitent. Ok?
I just don't agree. If you want persistent identifiers, you should
use URNs. But I can see your point. The fact is that I never assumed
the system was doing mandatory link integrity; so expressing that
you're a relation of a file which no longer is actually somewhere else
is not a big difficulty for me. You seem to think it's an absolute
nightmare situation whereas I don't.
However, I do see your point. My point is that the docreg file is not
the way to maintain persistant identifiers.
> But this can#t be solved with your proposal. If
> you move the documents
Sure....
> or the docreg files
Well, depending on the scheme you use (there's a relative to /usr/doc
*and* a relative to docreg file system, both of which are "normalized"
by install-docs for the mythical central store.
> you change the identifiers.
That's the risk with URLs! I'm willing to live with that, until we
have a URN system, or better yet, something based on XLink (drool
slobber).
The problem I have with your system is that it locks out URNs, URCs,
and other potentially useful ways (ISBNs) of identifying resources.
However, I don't want to appear to be completely oblivious to your
suggestion. How about I leave the syntax of the "Identifier" the same
and add as well an optional "Debian-identifier" element for those who
want to define persistent IDs. The in the "Relation" element or
whatever you could use the proprietary URL
"debian-id:<package>/<identifier>" syntax to notate this. This way
the whole thing is optional....
Would this sort of thing suffice?
> APH> * if we're going to be doing persistent identifiers, they need to be
> APH> centrally maintained anyhow (a single, global namespace), so a
>
> Why? They have to be unique and the package maintainer shouldn#t change
> the IDs of documents.
How do you propose we *enforce* this? We can't. That's another
reason why I don't like your scheme; I feel my comprimise solution is
ok though.
> No. Where#re the advantages of your solution?
The advantage of not using surrogate identifiers at all is the
following:
* no need to maintain global namespace of uniq ids (my comprimise of
"debian-id:<package>/<identifier>" solves this)
* no need to manage surrogate keys
Surrogate, globally unique keys are not an idea I want to foist on the
world, especailly w/o a strong centralized mechnanism. My comprimise
is to allow a light-weight translation system intead, and keep it
optional.
> What should I see above? I#ve proposed a unique ID and a file tag. I#ve
> never proposed a URN system for documents.
Why not? You should!
> Your proposal uses the identifier as URL/file. And this is a real bad idea
> and this breaks the DC idea.
Not at all. The DC system makes no claims in the persistance of the
identifier, and requires no such persistance (though it's always
nice).
BTW, you know that DC is on the IETF standards track now, right?
> For example I#ve added DC informations to all
> German HOWTO HTML files. And I#m using something like "dlhp DE-HOWTO.html"
> as Identifier and not our home page URL, because this would break all
> links, if I change my provider.
I'm fully aware of the problems of URLs, I can assure you.
> APH> ?? What is the "local name" of a book? Poor example here! ;)
>
> global name: ISBN 3-7785-2009-1
> local name (TUB-HH lib): NTG-310 and 2615-933 3
Yuck! WTF?
> P.S.: I#ve started to develop dhelp 0.4.x
Excellent. Please let us know any flaws in the system your
implementation work leads to. I'm starting the parsers already too.
Sorry they are all in perl still since my time is so short. Marco
thinks they *must* be in C. Any porters volunteer? Otherwise it
probably won't happen for a while.
--
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: