Mon application utilise URN: UUID comme URIS pour les entités. Bien sûr, quand je comprends, par ex. Informations sur RDF sur une ressource, les entités référées (sujets ou objets) contiendront URI dans l'urne: schéma UUID. Pour chercher la représentation de la nouvelle entité, éventuellement de manière possible, j'ai besoin d'un "résolveur", semblable à DX.Doij.org pour les Dois. Un autre cas pourrait être la résolution d'un ISBN: URI, afin d'obtenir une représentation raisonnable de cette URI.
Ma question est relative de ce qui est là-bas, en termes de normes proposées, pour la résolution de l'URL URI-Représentation.
4 Réponses :
Un UUID est un identifiant universellement unique, donc je ne vois donc pas comment vous seriez capable de résoudre un UUID que je viens de générer (par exemple 3136AA1A-FEC8-11DE-A55F-00003925D394) à quelque chose d'utile.
Ce n'est que si vous gérez une base de données d'Uuids quelque part, vous pouvez récupérer davantage de celui-ci. Ou vous devriez demander à tout le monde / tout "Connaissez-vous cet UUID?"
L'urne: UUID Définition définit un espace clair d'identificateurs uniques que vous pouvez utiliser pour définir quelque chose de vraiment unique. Mais comme personne d'autre d'autre ne peut deviner sa valeur, vous ne pouvez pas en tirer des informations.
Exactement, ce que je demande, c'est s'il y a une norme pour demander "Connaissez-vous cet UUID?"
Il n'y a pas de norme (proposée ou autre) pour résoudre une urne. C'est juste un nom (nom de ressource uniforme) et peut avoir une signification arbitraire.
XML / RDF crée une certaine confusion en utilisant des urnes qui résolvent parce qu'elles se trouvent également d'URL (localisateurs de ressources uniformes) qui pointent vers des objets décrivant leur signification, mais il s'agit simplement d'une convention. Ils doivent simplement être uniques et signifient toujours la même chose. P>
Si vous développez une application, vous pouvez envisager d'utiliser des urnes qui sont également des URL résolvables pour les articles avec une signification fixe et généré au hasard L'URN: UUID Espace de noms pour identifier les instances d'objets. P>
qui sonnait aussi déroutant que la spécification RDF: -) p>
Exemple rapide: P>
Tiger: http://www.example.com/animals/tiger Instance of a Tiger: urn:uuid:9a652678-4616-475d-af12-aca21cfbe06d
Oui, mais une fois que j'ai dit à quelqu'un "c'est l'urne d'objet: URN: UUID: 9A652678-4616-475D-AF12-ACA21CFBE06D" Comment peut-il trouver son URL? Qui est chargé de résoudre l'urne à l'emplacement de la représentation et avec quel protocole est la résolution effectuée. Comme vous le dites, il n'y a pas de norme, mais cela rendrait tout mappage entre toute urne et son emplacement impossible.
Il n'a pas d'URL. C'est un nom, pas un endroit. C'est la distinction que j'essaie de faire. (Confus l'enfer de moi la première fois que je rencontrais aussi des urnes). J'ajouterai de plus de précisions à la réponse.
Votre réponse est très perspicace et j'en ai appris quelque chose. Merci. Cependant, j'ai donné aux trempliers aux evains parce que j'ai eu quelques indications pour voir que la question est exceptionnelle, même à l'IETF.
Quickble mineur, Afaik Une URL n'est pas une urne: w3.org/tr/uri-clarification < / a> Je pense (sans regarder la norme RDF) que les objets sont nommés avec URI, ce qui signifie que vous pouvez utiliser une URL où que vous utilisiez une urne, car ils sont les deux URI.
@WDS qui doit être l'un des documents de clarification les plus obscurs que le W3C a déjà écrit! Vous êtes correct en ce que la spécification RDF est en termes d'URI (bien que la question était sur les urnes). Une meilleure clarification de la distinction peut être trouvée dans ietf.org/rfc/rfc2396.txt Section 1.2.
@Mike: Cela n'aide pas que la clarification n'est pas très clairement écrite. :-) Je pense toujours que vous êtes techniquement tort lorsque vous dites "URL sont des urnes valides" (elles sont à la fois des URIS valides). Oh et la note W3 existe également comme une RFC, je ne me souviens tout simplement pas du nombre.
@WDS: ... et vous avez également raison que je devrais avoir (principalement) référé à URI et non aux urnes. (Ai-je réussi à confondre l'autre lecteur de ce site de commentaires en acceptant votre correction d'une manière suffisamment obscure? :-) Bravo.)
Je pense que le tigre vs exemple du tigre est plus déroutant que utile. une ressource pourrait être une instance ou une catégorie d'instances. Mais une urne est absolue, tandis qu'une URL est un schéma spécifique pour localiser la ressource. Une ressource ne peut pas avoir plusieurs urnes , mais pourriez facilement avoir des URL infinies.
Le groupe de travail de l'URN conclu de l'IETF a également fait des travaux sur la résolution des urnes et publié de nombreux RFCs sur ce sujet. Une liste de références est contenue dans le Charte de groupe . Peut-être que certains d'entre eux vous aident.
Je vous accorde les tiques car j'ai trouvé de nombreuses RFC sur cette question et c'est certainement un point de départ pertinent. Celui-ci en particulier semble intéressant ietf.org/rfc/rfc2483.txt
One Indemness Uns est de donner aux gens la possibilité de créer des identifiants sans la responsabilité (implicite) du maintien d'un service décrivant les ressources sous-jacentes. Vous pourriez dire que pour RDF, c'est un avantage, mais pas une nécessité, mais vous seriez également moins enclin à utiliser un vocabulaire particulier, par exemple si vous avez découvert que ces URL HTTP ne sont plus déérique.
qui étant dit, certains urnes peuvent être retrouvés à leur représentation. Voici quelques exemples:
Il n'y a pas de mécanisme général pour la résolution d'urne et il ne peut en effet pas être (c'est également vrai pour d'autres schémas d'URI, comme parler spécifiquement des uuids, à mon avis, la meilleure façon de sortir de cela n'est pas d'utiliser une urne du tout. Si vous souhaitez utiliser un serveur Web pour la résolution, une méthode "standard" est d'utiliser le service Genid bien connu, votre URI principale serait donc quelque chose comme ceci: À ma connaissance, il n'y a qu'une seule méthode utilisée aujourd'hui pour créer un lien qui transmet la question "Savez-vous cette urne?", Eh bien, type de: A
ietf Espace de noms définit Plusieurs schémas d'identifiant , donc uris comme urne: IETF: RFC: 2648 peut être résolu si vous implémentez les modèles spécifiques.
URN: IETF: parames: xml: avec les fichiers correspondants pour les ressources.
urn: ISBN: (certaines métadonnées peuvent être récupérées, mais je ne pense pas qu'il y ait quelque chose qui vous permettra de télécharger le livre de Son isbn), urne: OID: . Il y a aussi urn: publicid: , certains des identificateurs peuvent être trouvés quelque part au fond de l'ISO.
Tag: ).
http: / /example.org/.well-nown-nowndf9f0-A9C5-4E8A-9762-844A33BA7A3E . Si vous hébergez RDF à cet endroit, il n'y a rien de mal à ajouter hibou: samas Magnet: Link . Il n'y a rien de principe qui vous obligerait à utiliser un hasch là-bas comme si vous trouvez habituellement, alors quelque chose comme Magnet:? XT = URN: UUID: B47DF9F0-A9C5-4E8A-9762-844A33BA7A3E pourrait fonctionner, à condition que vous ayez votre propre client qui peut gérer cela.
Je ne suis pas sûr de bien comprendre la question, mais pourquoi y aurait-il même une représentation pour une urne donnée?
S'il y en a, vous devriez être capable de le résoudre si le résolu est essentiel. À l'heure actuelle, je peux parler d'un ISBN, mais le seul moyen de résoudre cet ISBN est d'aller à Amazon et d'acheter la version Kindle. Idem pour un dodi. Vous allez à DOI.ORG et résolvez-le. Mais il n'y a pas de norme pour cela. Je suis intéressé par la norme, si elle existe.