- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Thu, 17 Jan 2002 09:38:47 +0200
- To: Michael Mealling <michael@neonym.net>
- CC: URN <URN-IETF@LISTS.NETSOL.COM>, URI <uri@w3.org>
On 2002-01-16 16:31, "ext Michael Mealling" <michael@neonym.net> wrote: > On Wed, Jan 16, 2002 at 02:41:06PM +0200, Patrick Stickler wrote: >> The following internet drafts have been submitted to the IETF >> for consideration: > > Hi Patrick, > I assume you knew you were stiring up a hornets nest, right? ;-) I'm quite aware that the issues that are addressed in my IDs are areas of strong debate, yes. >> "An Extended Class Taxonomy for Uniform Resource Identifier Schemes" >> http://www-nrc.nokia.com/sw/draft-pstickler-uri-taxonomy-00.html > > Being one of the people in the URI-IG that discussed the classical vs > contemporay view (and an adherent of the contemporary view) I have to > say > that this way lies madness. Perhaps you missed the part that said that it is compatible with either the classical or contemporary view? Let me stress it again, draft-pstickler-uri-taxonomy-00 is compatible with either the classical or contemporary view. If you read it without this understanding, I would encourage you to read it again. > Most of the people on the URI-IG were > involved > in the original discussions about URIs when we had such animals as > URA, URMs, URCs, URAv2, etc. The thing that has become clear is that > a given URI's characteristics have more to do with how it is used than > what its scheme says. Use and abuse are two different things. I assert that any use of a URI scheme contrary to the specified intended use is contrary to the very purpose of standards, and while research and advancement often need to bend the rules and try unconventional things, eventually, advancements and improvements need to be addressed in a standardized manner such that industry can build upon that knowledge in a consistent and reliable manner. > For example, Dan uses the http scheme for > pretty much everything. For him the http scheme makes a pretty valid > urn-like thing. Others don't use it that way so it doesn't have those > semantics for them and thus isn't one. IMO, a URI scheme defines, in addition to the syntax, a common semantics and basis for interpretation of instances of that scheme so that an application has at least half a clue what to do with such instances. Otherwise, let's all just use uuid: URIs and define the semantics in RDF. > The one thing I do have a problem with is the inclusion of 'hrn:' > along side 'urn:'. IMHO, since your 'hrn' proposal includes a > domain-name > it cannot be a URN because it is not persistent. The UUID version might > but the domain-name based one isn't.... You missed the essential point about my extended taxonomy and the definition of a URN -- that while a URN may embody within its representation the identity of the minting agent, it does not embody the identity of the resolution agent. URLs do both -- and in fact, the minting and resolution agents are the same. I suggest you re-read draft-pstickler-uri-taxonomy-00, particularly section 3. An 'hrn:' may include the web authority of the minting agent, and that is persistent, as that will never change. Unlike a URL, however, that is *not* the resolution authority -- which like all URNs -- remains undefined in the URI itself. The 'hrn:' scheme provides a consistent, open, non-centralized URN scheme that does not need a dedicated centralized authority for granting namespaces, but uses web authority as that namespace and thus is far better suited for the Web, not having the bottleneck of namespace registration preventing global and mass minting of URNs. Furthermore, the 'hrn:' URN scheme is a hierarchical URI scheme, which is highly desireable for many applications. By those two criteria, I consider the 'hrn:' URN scheme to be superior to the 'urn:' URN scheme -- though both are fully valid URN schemes in that neither refer to any resolution agency explicitly in their representation and are hence persistent in that regard. > Beyond that the analysis is good from that point of view. The problem is > getting agreement on it... Absolutely. Agreement about URI classes (or lack thereof) and URI semantics will be a long road, I think. But even though I'm coming late to this party, I think I've brought along some rather good music, and maybe we can all get into the same groove ;-) >> "The 'hrn:' URI Scheme for Hierarchical Resource Names" >> http://www-nrc.nokia.com/sw/draft-pstickler-hrn-00.html > > As mentioned above, I think that this statement is erroneous: > "This URI scheme is also a type of URN, as defined by RFC 2396, but is > not a > namespace of the 'urn:' URI scheme [5], because the 'urn:' scheme does > not provide for hierarchical characteristics which are central to the > semantics of this URI scheme. " > > The fact that there is a domain-name in there means that it violates > the persistence requirement in RFC 2396. But this persistence requirement has the rather narrow view that a web authority (domain name) only indicates a resolution agency, and that the URL-centric perspective perhaps precludes the broader role of a domain name representing only the minting agency, which even if that domain ceases to exist, remains historically valid and thus persistent -- within the scope of URN schemes which only attribute significance with regards to minting and not to resolution. >> "The 'uri:' URI Scheme for URI Reification" >> http://www-nrc.nokia.com/sw/draft-pstickler-uri-00.html > > This is an interesting one but I think you should pick another scheme > name. > The one you picked will end up causing you to much argument over the > name > and none over the merits of the idea. The one question I have is: is > reification so globally well understood that it means the same thing to > everyone? I've been out of the RDF discussions but I seem to remember > this being an issue at one point.... This URI scheme is specifically intended for use within RDF applications. And as for the name, it seems quite consistent with the URN/urn: convention ;-) After all, not all URNs are urn:'s. Likewise, not all URIs are uri:'s. But all urn:'s are URNs and all uri:'s are URIs. >> "The 'tdl:' URI Scheme for Typed Data Literals" >> http://www-nrc.nokia.com/sw/draft-pstickler-tdl-00.html > > What is the merit of this over the 'data:' scheme? Specific, constrained semantics. Furthermore, the 'data:' URI scheme requires that all datatypes be registered/defined as MIME types, which is an unnecessary overhead IMO for the kinds of datatypes in question. The 'tdl:' approach is that each datatype is denoted by a URI, and the pairing of datatype URI and lexical form uniquely identifies a member of the value space of the datatype. This is based on one proposal under consideration by the RDF Core Working Group for datatyping of literals in RDF. C.f. http://www-nrc.nokia.com/sw/TDL.html While the 'data:' URI scheme *could* be made to work for this application, it would be cumbersome. >> "The 'voc:' URI Scheme for Vocabulary Terms and Codes" >> http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html > > I can't figure out what this scheme has that doesn't already exist in > current schemes. It seems that this one definitely falls into the "a > URI's > semantics have more to do with how you use it than what the scheme has > in it".... Again, perhaps its significance is not seen because the distinction between URI classes as defined in draft-pstickler-uri-taxonomy-00 section 3 is not fully understood. The key point is that a 'voc:' URI does not resolve to "something else". It is a URP. Yes, you could define a similar URI using 'http:' but it would never be clear whether it should or should not resolve to anything, and if so, to what. This is the basis for the classical view that I openly admit to subscribing to. The URI scheme lets an application know what it should or should do with a given URI. Using 'http:' URLs for everything just leaves the application guessing. The syntactic similarities between 'voc:' and 'http:' are due to both of them being hierarchical URI schemes and utilizing web authorities -- but their semantics are *very* different. >> "The 'qname:' URI Scheme for XML Namespace Qualified Names" >> http://www-nrc.nokia.com/sw/draft-pstickler-qname-00.html > > Hmm.... I don't think a URI scheme can disclaim the URI Reference so the > hash mark statement is false. Under the currently defined URI Class taxonomy, consisting only of URLs and URNs, no -- but under my extended URI taxonomy, with URPs, it can. And actually, since the definition of a URI Reference is based on the *returned* media type from dereferencing a URI, and if a given URI scheme is never intended to be dereferenced, then it is IMO valid and reasonable to state that in such cases a URI Reference is simply undefined (cannot exist, or is vacuous). > hmm... This one also really strikes me > as shortcutting RDF statements by putting them into the URI scheme > itself. I.e. all of the examples are previously stated URI examples from > other documents with an XML element name in front of it. Is it wise to > be > creating new URI schemes when a statement in RDF could do the same > thing? This URI scheme has nothing to do with RDF/XML serialization. The utility of this URI scheme is to achieve intersection of knowledge in a 'tidy' RDF graph. "Constellations" of property/value pairs do not constitute equality in the eyes of RDF insofar as graph merging is concerned. A URI representation results in there being one and only one node in an RDF graph for each qualified name and allows one to make statements about that qualified name resource which are global to the knowledge base. >> "The 'xmlns:' URI Scheme for XML Namespace Declarations" >> http://www-nrc.nokia.com/sw/draft-pstickler-xmlns-00.html > > I thought we'd fixed that whole XML namespace thing? 1. XML Namespaces still remain problemmatic in several areas, but that is a totally disjunct discussion that I won't introduce here to this forum, especially since it is not relevant to the 'xmlns:' URI scheme itself. 2. The 'xmlns:' URI Scheme does not replace XML NS declarations in XML instances. As with 'qname:' it provides a consistent representation for NS declarations in an RDF knowledge base (or anywhere else such a representation is useful). >> "The 'auth:' URI Scheme for Hierarchical Authority Identifiers" >> http://www-nrc.nokia.com/sw/draft-pstickler-auth-00.html > > What's the difference between this and an 'http:' scheme? 1. It's a URV 2. It can be temporally qualified. 3. Its semantics are explicitly constrained to the representation of authoritative agents. >> Any and all comments are most welcome. > > Sorry if it sounds like I was picking it apart. No need for apologies, I wan't folks to pick them apart. That's how (a) they get better, and (b) how we achieve agreement. > Its just that some of > these > ideas were discussed in other fora which is how we got to the "its how > you use it, not the scheme name that's important" idea... As I said, I know I'm coming late into these discussions (or have missed them entirely ;-) but I sincerely feel that the contemporary view is missing something very important and essential -- perhaps not so essential for the Web, but definitly essential for the Semantic Web. Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Received on Thursday, 17 January 2002 02:37:59 UTC