Re: Re^10: Debian Metadata Proposal -- draft rev.1.4
Marco, I assume you followed up to debian-devel by accident.
Redirected to debian-doc.
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> APH> > Identifier: <package> <could be choosen by the maintainer>
> APH> > File: <path, should be relative to the docreg file>
> APH> I disagree with this. If you want persistent resource identifiers,
>
> A identifier should always persitent.
Should perhaps. My conclusion, which you have never been able to
refute, is the identifier maintenance should *not* be done in docreg
files but rather in a separate subsystem, used by Debian Metadata, as
well as by, say, debiandoc-sgml, etc.
This is a design decision. I agree I'd like to see Debian embracing
persistent document idenfiers in some cases, but I rabidly disagree
that docregs files should be the medium for this maintenance.
* what if I want to refer to a document that I haven't installed?
* what if I want to maintain possible URN->URLs for network use from a
central location (i.e., I'm the DDP maintainer)
* if we're going to be doing persistent identifiers, they need to be
centrally maintained anyhow (a single, global namespace), so a
non-centralized system for this is not going to fly
Finally,
* while I agree that I'd like to see persistent identiifers in Debian
(URNs), I don't think they are absolutely necessary for the debian
metadata system, therefore, I ask for volunteers in getting this
going, and I'm not going to wait for it. For instance, if a package
is yanked from a distribution, suddenly that so-called "persistent"
identifier is gone. Doesn't sound very persistent to me!
> APH> we've got to go with a URN/URL scheme. Notating *persisten*
>
> Not really. At the moment URN is no standard (and DC, too) and the
> suggestions for the URN scheme are useless for a local system like docreg.
> We can#t force the user to use a network based system.
Absolute FUD. You *can* do URN->URL translation on a local,
non-networked system. It's called CGI, using a local list of URN/URL
translations, for instance, using a debian-urnlist package which
allows users to install updated URN/URL translations.
Using draft standards is better than making up (and poorly designing)
our own system.
> APH> identifiers in docreg files (containers for metadata) is not
>
> Why? We wouldn#t break the DC "standard" and we would solve a lot of
> problems.
See above. We'd create more problems.
> APH> acceptable and would indeed be very poor design.
>
> Why? It solves our problems. Remember we#re talking about local files! We
> could of course use the DC idea, but we have to add new tags for our
> needs.
I'm not against adding new tags. And yes, it's explicitly allowed by
DC. But the design you proposed is very poor (see above).
> APH> resource may have multiple metadata entities referring to them. Do
>
> And where#s the problem with my solution? This is not possible with your
> solution, because you would always have the same identifier!
Sure it's possible in my solution. Metadata have no identifier.
Files may have URNs. Two metadatas could reference the same
Identifier (URL or URN).
> APH> you start to see why your scheme is impractical? In your scheme, the
>
> No, I don#t. Maybe I could give a example of a library: a book has always
> a unique identifier (ISBN) and it has a local name (like a local filename
> in my proposal).
?? What is the "local name" of a book? Poor example here! ;)
> APH> This is not an appropriate job for a metadata entity to do, since a
>
> And using a local filename as identifier is a better solution? Strange.
It's a better interim solution than poor design.
--
.....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: