Re^10: Debian Metadata Proposal -- draft rev.1.4
Am 23.07.98 schrieb apharris # burrito.onshore.com ...
Moin Adam!
APH> > No, as I#ve showed we need a "real" ID. With you solution you can#t
APH> > move a original to another directory or change the filename without
APH> > breaking all translation and auto-converted links to the original. This
APH> > is a bad design.
APH> I disagree with your conclusion.
Why? Maybe you should consider why a lot of people are talking about
things like URN: because the path/name of a HTML file could change and
this would break all links to this document.
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.
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.
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.
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.
APH> Identifiers do not identify the metadata but they identify the
APH> resource. Do you understand this distinction? Furthermore, a single
I#m not interested in any kind of formal distinction! We#re talking about
a small file format for local use only! If we need some informations in
such a file, we add it.
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!
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).
APH> metadata entity is the one constructing the actual resource
APH> identifiers, as well as the mapping from resource-ids to pathnames.
That#s right. And where#s the problem? See my example. I don#t understand,
why we should map one information several times. That#s nonsense.
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.
APH> Furthermore, several metadata entities might ascribe new resource-ids
APH> to the same file name!
Not to the same file name (because the file is owned by one Debian
package) but to one URL, right.
APH> How are we supposed to manage resource-ids and
APH> how they map to file names in this scheme?
I don#t understand that. Every identifier would have only one filename
(but one filename could have several identifiers). Where#s the problem?
APH> If you really want persistent identifiers for resources, you have to
APH> manage them out of the metadata...
No. The filename is part of one docreg entry. And every docreg entry has
got one identifier. One file could have several identifiers.
APH> I suggest you start hacking on the
APH> URN2URL stuff ASAP then. It's up to you.
Again, I#m not interested in such a solution. I don#t see an advantages.
APH> You arguments are weak and do not compel me. Give me better arguments
APH> and we shall all discuss it.
But where#re you solutions for the problems of your proposal?
APH> Have you read the spec v0.8.0?
No (I don#t have a lot of time), but I#ll read it this afternoon.
cu, Marco
--
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com http://www.tu-harburg.de/~semb2204/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: