解析 urn:uuid （和其他）的标准？
我的应用程序使用 urn:uuid 作为实体的 URI。当然，当我获得例如有关资源的 RDF 信息时，所引用的实体（主题或对象）将包含 urn:uuid 模式中的 URI。为了获取新实体的表示（可能以 REST 方式），我需要一个“解析器”，在某种程度上类似于 DOI 的 dx.doi.org。另一种情况可能是 isbn: URI 的解析，以便获得该 URI 的合理表示。
我的问题与 URI 到表示 URL 解析的拟议标准有关。
My application uses urn:uuid as URIs for entities. Of course, when I get, e.g. RDF information about a resource, the referred entities (subject or objects) will contain URIs in the urn:uuid schema. To fetch the representation of the new entity, possibly in a REST way, I need a "resolver", similar in some way to dx.doi.org for DOIs. Another case could be the resolution of a isbn: URI, so to obtain a sensible representation of this URI.
My question is relative to what's out there, in terms of proposed standards, for URI-to-representation-URL resolution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
已结束的 IETF URN 工作组也在解决 URN 方面做了一些工作，并就此主题发布了相当多的 RFC。 团体章程中包含参考列表。也许其中一些对您有帮助。
The concluded URN Working Group of the IETF has also done some work on resolving URNs and published quite a few RFCs on this topic. A list of references is contained in the group charter. Maybe some of them help you.
没有用于解析 URN 的标准（建议的或其他的）。它只是一个名称（统一资源名称）并且可以具有任意含义。
XML/RDF 通过使用确实可以解析的 URN 造成了一些混乱，因为它们碰巧也是 URL（统一资源定位器），指向描述其含义的对象，但这只是一种约定。它们只需要是唯一的并且始终意味着相同的事情。
如果您正在开发应用程序，您可能需要考虑使用 URN，它们也是具有固定含义的项目的可解析 URL，并在 urn:uuid 命名空间中随机生成 URN 来标识对象的实例。
这听起来和 RDF 规范一样令人困惑:-)
简单的例子：
http:// /www.example.com/animals/tiger，但不一定有。这只是一个约定。
[添加了其他说明]
此处的区别在于 URN（名称）和 URL（位置）之间。
URN 只是命名一些东西。它不是任何东西的位置。
URL 是有效的 URN，因此您可以根据需要使用 URN 的 URL。
在上面的示例中，我可以使用例如 http://www.example。 com/tigers/9a652678-4616-475d-af12-aca21cfbe06d 作为我的老虎的名字。我可以在那个地址放一些东西。但我会在那里放什么？你无法使用 http 下载 Tiger 的实例！
RDF 中的约定是，如果 URN 也是 URL，它将指向一些定义该名称含义的文档。
RDF 试图为您提供一种命名事物的约定，以确保当两个人使用相同的名称时，他们表示相同的事物。 UUID 规范允许您为某些内容生成一个唯一的名称，该名称不可能被其他任何东西使用。但这只是一个名字，并没有办法把它变成一个东西。
希望这有帮助。
There is no standard (proposed or otherwise) for resolving a URN. It's just a name (Uniform Resource NAME) and may have arbitrary meaning.
XML/RDF creates some confusion by using URNs which do resolve because they happen to also be URLs (Uniform Resource Locators) which point to objects describing their meaning, but this is merely a convention. They merely have to be unique and always mean the same thing.
If you are developing an application, you might want to consider use URNs which are also resolvable URLs for items with fixed meaning, and randomly generated URN's in the urn:uuid namespace to identify instances of objects.
That sounded about as confusing as the RDF spec:-)
Quick example:
There might be a HTML page at http://www.example.com/animals/tiger, but there doesn't have to be. It's merely a convention.
[Additional Clarification Added]
The distinction here is between URNs (Names) and URLs (Locations).
A URN just names something. It's not a location of anything.
URLs are valid URNs, so you can use a URL for a URN if you want to.
In the above example, I could use e.g. http://www.example.com/tigers/9a652678-4616-475d-af12-aca21cfbe06d as the name of my tiger. I could put something at that address. But what would I put there? You can't download an instance of a tiger using http!
The convention in RDF is that if a URN is also a URL, it will point at some documentation defining what the name means.
What RDF is trying to give you is a convention for naming things which ensures that when two people use the same name, they mean the same thing. The UUID specification allows you to generate a unique name for something which is not likely to be used by anything else. But it's just a name, and there's no way of turning it into a thing.
Hope this helps.
UUID 是一个通用唯一标识符，因此我不知道如何将我刚刚生成的 uuid（例如 3136aa1a-fec8-11de-a55f-00003925d394）解析为有用的东西。
只有当您在某处管理 uuid 数据库时，您才能从中检索更多信息。或者你必须问每个人/所有事情“你知道这个 uuid 吗？”
urn:uuid 定义定义了唯一标识符的清晰空间，您可以使用它来定义真正唯一的东西。但由于没有其他人可以猜测它的价值，因此您无法从中获取信息。
An UUID is a universally unique identifier, so I don't see how you would be able to resolve a uuid I just generated (e.g. 3136aa1a-fec8-11de-a55f-00003925d394) to something useful.
Only if you manage a database of uuids somewhere, you can retrieve more from it. Or you would have to ask everyone/everything "Do you know this uuid?"
The urn:uuid definition defines a clear space of unique identifiers you can use for defining something truly unique. But as nobody else can guess its value, you can't derive information from it.
URN 存在的原因之一是让人们有机会创建标识符，而无需承担维护描述底层资源的服务的（隐式）责任。您可以说，对于 RDF 来说，这是一个优势，但不是必需的，但是您也不太愿意使用特定词汇表，例如，如果您发现这些 HTTP URL 不再是可取消引用的。
话虽这么说，一些 URN 可以追溯到它们的表示。以下是一些示例：
ietf命名空间定义了几种标识符方案< /a>，因此如果您实现特定模式，则可以解析像urn:ietf:rfc:2648这样的 URI。urn： ietf:params:xml:以及资源的相应文件。urn:isbn:（可以检索一些元数据，但我认为没有任何东西可以让您从其 ISBN 下载该书） ，urn:oid:。还有urn:publicid:，其中一些标识符可以在 ISO 深处的某个地方找到。URN 解析没有通用的机制，实际上也不可能有（对于其他 URI 方案也是如此，例如
tag:；但是有一些机制，例如 WebFinger，当您知道目标服务器时，有助于 URI 解析）。具体到 UUID，在我看来，解决这个问题的最佳方法是根本不使用 URN。如果您想使用 Web 服务器进行解析，“标准”方法是使用众所周知的没有任何问题。
genid服务，因此您的主要 URI 将如下所示：http:// /example.org/.well-known/genid/b47df9f0-a9c5-4e8a-9762-844a33ba7a3e。如果您在该位置托管 RDF，则在必要时添加 owl:sameAs据我所知，目前只有一种方法可以创建一个链接来传达“你知道这个 URN 吗？”这个问题，嗯，有点：
magnet:链接。原则上没有什么要求您像通常那样使用哈希，因此像magnet:?xt=urn:uuid:b47df9f0-a9c5-4e8a-9762-844a33ba7a3e这样的东西可以工作，前提是您有自己的客户可以处理这个问题。One reason URNs exist is to give people the opportunity to create identifiers without the (implicit) responsibility of maintaining a service that describes the underlying resources. You could say that for RDF this is an advantage, but not a necessity, but you'd also be less inclined to use a particular vocabulary for example if you discovered that those HTTP URLs are no longer dereferenceable.
That being said, some URNs can be traced back to their representation. Here are some examples:
ietfnamespace defines several identifier schemes, so URIs likeurn:ietf:rfc:2648can be resolved if you implement the specific patterns.urn:ietf:params:xml:with the corresponding files for the resources.urn:isbn:(some metadata can be retrieved, but I don't think there is anything that will allow you to download the book from its ISBN),urn:oid:. There is alsourn:publicid:, some of whose identifiers may be found somewhere deep inside ISO.There is no general mechanism for URN resolution, and indeed there cannot be (that is also true for other URI schemes, like
tag:; there are however some mechanisms such as WebFinger that facilitate URI resolution when you know the target server).Talking specifically about UUIDs, in my opinion, the best way out of this is not to use a URN at all. If you want to use a web server for the resolution, a "standard" way is to use the
genidwell-known service, thus your primary URI would be something like this:http://example.org/.well-known/genid/b47df9f0-a9c5-4e8a-9762-844a33ba7a3e. If you host RDF at that location, there is nothing wrong with addingowl:sameAs <urn:uuid:b47df9f0-a9c5-4e8a-9762-844a33ba7a3e>there if you have to.To my knowledge, there is only one method that is in use today to create a link that conveys the question "Do you know this URN?", well, kind of: a
magnet:link. There is nothing in principle that would require you to use a hash there like you usually find, so something likemagnet:?xt=urn:uuid:b47df9f0-a9c5-4e8a-9762-844a33ba7a3ecould work, provided you have your own client that can handle that.