[EMAIL PROTECTED] (Marco Budde) writes: [...] > APH> > you change the identifiers. > APH> That's the risk with URLs! > > But we#re not using URLs for local files!
Sure we are... relative URLs. Read the specs. [...] > APH> The problem I have with your system is that it locks out URNs, URCs, > APH> and other potentially useful ways (ISBNs) of identifying resources. > > No, that#s not true. I#m using the Identifier tag as an identifier for a > docreg element and not for a document. Then you shouldn't call it identifier because that's not what 'Identifier' means. There is no facility for self-referentiality in Dublin Core, which might be a weakness, but I don't understand why we need it for what we're doing here. Can you explain exactly why you think we need a unique ID for metadata entities? > For example you could have to > versions (PS, HTML) of one book. And so we can#t use the ISBN number as > identifier. Um, if my entity said "Identifier: isbn:XX-YY-ZZZZZ" then clearly I am referring to a published book with the given ISBN, not a file! > And you could of course use URNs for the "File: " line. Maybe we should > use another name for "File: " like "URL: ". Why the fsck would we do that? That's just extremely silly. 'file:...' is exactly for this purpose. > APH> However, I don't want to appear to be completely oblivious to your > APH> suggestion. How about I leave the syntax of the "Identifier" the same > APH> and add as well an optional "Debian-identifier" element for those who > APH> want to define persistent IDs. The in the "Relation" element or > APH> whatever you could use the proprietary URL > APH> "debian-id:<package>/<identifier>" syntax to notate this. This way > APH> the whole thing is optional.... > > Right and that is bad. I#m working on a translation document, I have to > ask the maintainer of the original document to release a new version with > this debian-identifier. ?? No you can just refer to the pkg/file where you got it from! If there's no "Debian-Identifier" then, clearly, you can't use it anyway. > APH> Would this sort of thing suffice? > > No, I don#t see your problem with my solution. The unique identifier > shouldn#t be optional. I don#t understand, why you like using filenames as > identifier. This is not required by the DC "standard". No, but identifiers point to files, not to metadata. You don't seem to grasp that. Metadata itself are not first-class citizens. > The identifier should be unique and pseudo persitent in the docreg system. > That#s why we should use your debian-id als "Identifier: ". How do you intend it to be unique? How can you enforce that? Use the package name? But what if the package changes its name? Or what if the doc is split out into another package? See, the whole problem with your proposal, and I've said this again and again, is that you are trying to stuff two kinds of entities into docreg: persistent names for resources (lets call these m-ids, just for clarity), and the metadata for resources. By coupling these together into docreg files, you are inviting serious trouble. In your scheme, it is impractical or impossible to do the following: * remove m-ids once the are created * rename m-ids * refer to m-ids in packages that are not installed, i.e., on a Debian Documentation mirror (relevant to the Relation.* fields) * enforce uniqueness on m-ids, and lack of enforced uniqueness is a bug in your scheme * associate metadata with non-local URLs (i.e., http://www.debian.org/) Given all these weakness, I just feel that your scheme really isn't much better than just referring to a URL. Do you see my fundamental point? docreg files manage *metadata*. Metadata is information about a resource. You are proposing to also manage these things called 'm-ids' in the docreg files. 'm-ids' and 'resource metadata' are two different entities. But you are describing them within a single unit. This is a fundamental flaw. You are proposing to require that ever metadata entity in a docref file contains not only metadata, but also manages these entities called 'm-ids'. I feel that m-id management should not be tied to the actual metadata, and that it is orthogonal. When I talk about URNs, I'm basically saying the same thing as you, but pointing out that m-id management is it's own beast; as such, it should be globally tracked and stored and managed on it's own. Furthermore, my scheme lets you intermix normal 'file:' references, 'http:', 'news:', 'mailto:', whatever. So it's working with existing standards, whereas you are blowing them away for no good reason. > APH> reason why I don't like your scheme; I feel my comprimise solution is > APH> ok though. > > I don#t see any differences for this topic. There's a huge difference between requiring and just allowing. > APH> * no need to maintain global namespace of uniq ids (my comprimise of > APH> "debian-id:<package>/<identifier>" solves this) > > Sorry, but you#re 100% wrong :). I#ve suggested to use > <package><free name> as identifier. So where#s the need to maintain a > global namespace of uniq ids? I don#t see that. If the namespace isn't unique, then there is no benefit to your solution at all, since refering to your identifiers doesn't mean anything anymore. I.e., any given package could break your links by stomping on the m-id you use in the Relation.* fields. > But with your solution you#ve to maintain it! If to packages add the same > URL (for example to www.debian.org) you have got a problem! Huh? I don't know, I think I would like to see your scheme presented in full. I just don't see how you are dealing with * managing m-ids * the "Relation.*" fields * intermixing local files and WWW pages * allowing any given URL (i.e., 'news:comp.os.linux.announce'; would you put this in the horribly named 'Files' field?!) Maybe I just don't understand your proposal. -- .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
