OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Catalog Requirements

At 14:27 2000 11 20 -0500, Norman Walsh wrote:
>The interesting question is, what are we going to do about delegation?
>Off the top of my head, I see a small conflict. Delegation makes sense
>for public identifiers (as described in TR9401), but it also makes
>sense for URNs, which could apply across categories. Hmmm....

I fear you're confusing things again when you appear to compare 
public ids and URNs--you're comparing contextual function with data type.

Delegation makes sense for any lefthand side that is interpretable
in some hierarchical way.  In fact, given Formal Public Identifiers 
and system ids (the latter of which often take the form of 
hierarchical file names or URLs), system ids are often more obviously
hierarchical than public ids, so one could argue that delegation
makes more sense for SYSTEM identifiers than PUBLIC identifiers.
It's just that TR9401 didn't even originally map SYSTEM, so when
delegation was first considered, it was for PUBLIC ids.

So think of the current DELEGATE entry type as meaning
"delegate public ids" and realize that we could add entry types
to "delegate system ids", "delegate namespace names", and so forth.

But we should not consider "delegate URNs" any more than we should
consider "map URIs" in an external entity identifer resolution catalog.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC