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

Re^10: Debian Metadata Proposal -- draft rev.1.4



Ups, wrong list:

## Nachricht vom 24.07.98 weitergeleitet
## Ursprung : /USENET/MLIST.DEBIAN.ORG
## Ersteller: Marco.Budde # hqsys.antar.com@243:9000/0

From: Marco.Budde@hqsys.antar.com (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: 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



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


Reply to: