Re: Re^14: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (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. 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: