Ups, wrong list: ## Nachricht vom 24.07.98 weitergeleitet ## Ursprung : /USENET/MLIST.DEBIAN.ORG ## Ersteller: Marco.Budde # [EMAIL PROTECTED]:9000/0
From: [EMAIL PROTECTED] (Marco Budde) 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: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED] http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
