As pessoas falam sobre URLs , URIs e URNs como se fossem coisas diferentes, mas parecem iguais a olho nu.
Quais são as diferenças distinguíveis entre eles?
( URIs ( URLs ) )
As pessoas falam sobre URLs , URIs e URNs como se fossem coisas diferentes, mas parecem iguais a olho nu.
Quais são as diferenças distinguíveis entre eles?
( URIs ( URLs ) )
Respostas:
Do RFC 3986 :
Um URI pode ainda ser classificado como localizador, nome ou ambos. O termo "URL (Uniform Resource Locator") refere-se ao subconjunto de URIs que, além de identificar um recurso, fornece um meio de localizar o recurso, descrevendo seu mecanismo de acesso primário (por exemplo, sua "localização" da rede). O termo "Nome Uniforme do Recurso" (URN) tem sido usado historicamente para se referir aos dois URIs no esquema "urna" [RFC2141] , que devem permanecer globalmente únicos e persistentes, mesmo quando o recurso deixa de existir ou fica indisponível, e para qualquer outro URI com as propriedades de um nome.
Portanto, todos os URLs são URIs (na verdade, não exatamente - veja abaixo), e todos os URNs são URIs - mas URNs e URLs são diferentes, portanto, você não pode dizer que todos os URIs são URLs.
EDIT: Eu pensava anteriormente que todos os URLs são URIs válidos, mas conforme os comentários:
Nem "todos os URLs são URIs". Depende da interpretação do RFC. Por exemplo, em Java, o analisador de URI não gosta
[
ou]
e isso ocorre porque a especificação diz "não deve" e não "não deve".
Infelizmente, isso atrapalha ainda mais as águas.
Se você ainda não leu a resposta de Roger Pate , aconselho fazê-lo também.
[
ou ]
e isso ocorre porque a especificação diz "não deve" e não "não deve".
java.net.URI
documento diz que "todo URL é um URI, falando abstratamente, mas nem todo URI é um URL". E java.net.URL
faz coisas estranhas, como verificar a igualdade de URLs, resolvendo nomes de host para endereços IP (o que parece em desacordo com a RFC 3986 sec 6 em primeiro lugar e quebra os hosts virtuais). Eu acho que isso significa apenas que a Java Standard Library tem algum comportamento de classe inconsistente.
Os URIs identificam e os URLs localizam ; no entanto, os localizadores também são identificadores ; portanto, todo URL também é um URI, mas há URIs que não são URLs.
Este é o meu nome, que é um identificador. É como um URI, mas não pode ser um URL, pois não informa nada sobre minha localização ou sobre como entrar em contato comigo. Nesse caso, também identifica pelo menos outras 5 pessoas somente nos EUA.
Este é um localizador, que é um identificador para esse local físico. É como um URL e um URI (já que todos os URLs são URIs) e também me identifica indiretamente como "residente de ..". Nesse caso, ele me identifica exclusivamente, mas isso mudaria se eu conseguisse uma colega de quarto.
Eu digo "gosto" porque esses exemplos não seguem a sintaxe necessária.
Da Wikipedia :
Na computação, um URL (Uniform Resource Locator) é um subconjunto do URI (Uniform Resource Identifier) que especifica onde um recurso identificado está disponível e o mecanismo para recuperá-lo. No uso popular e em muitos documentos técnicos e discussões verbais, é frequentemente usado incorretamente como sinônimo de URI , ... [ênfase minha]
Devido a essa confusão comum, muitos produtos e documentação usam incorretamente um termo em vez do outro, atribuem sua própria distinção ou usam-na como sinônimos.
Meu nome, Roger Pate, poderia ser como um URN (Uniform Resource Name), exceto aqueles são muito mais regulado e destinam-se a ser único em ambos espaço e tempo.
Como atualmente compartilho esse nome com outras pessoas, ele não é globalmente exclusivo e não seria apropriado como URN. No entanto, mesmo que nenhuma outra família usasse esse nome, eu sou o nome do meu avô paterno, por isso ainda não seria único ao longo do tempo. E mesmo que não fosse esse o caso, a possibilidade de nomear meus descendentes depois de mim torna isso inadequado como URN.
Os URNs são diferentes dos URLs nessa restrição rígida de exclusividade, embora ambos compartilhem a sintaxe dos URIs.
URNs are different from URLs in this rigid uniqueness constraint
Isso significa que os URLs não identificam exclusivamente um local?
Os URIs são um padrão para identificar documentos usando uma sequência curta de números, letras e símbolos. Eles são definidos pelo RFC 3986 - Identificador Uniforme de Recursos (URI): Sintaxe Genérica . URLs, URNs e URCs são todos os tipos de URI.
Contém informações sobre como buscar um recurso a partir de sua localização. Por exemplo:
http://example.com/mypage.html
ftp://example.com/download.zip
mailto:user@example.com
file:///home/user/file.txt
tel:1-888-555-5555
http://example.com/resource?foo=bar#fragment
/other/link.html
(Um URL relativo, útil apenas no contexto de outro URL)Os URLs sempre começam com um protocolo ( http
) e geralmente contêm informações como o nome do host da rede ( example.com
) e geralmente um caminho do documento ( /foo/mypage.html
). Os URLs podem ter parâmetros de consulta e identificadores de fragmento.
Identifica um recurso por um nome exclusivo e persistente, mas não indica necessariamente como localizá-lo na Internet. Geralmente começa com o prefixo urn:
Por exemplo:
urn:isbn:0451450523
para identificar um livro pelo seu número de ISBN.urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
um identificador globalmente exclusivourn:publishing:book
- Um espaço para nome XML que identifica o documento como um tipo de livro.URNs podem identificar idéias e conceitos. Eles não estão restritos à identificação de documentos. Quando um URN representa um documento, ele pode ser traduzido em um URL por um "resolvedor". O documento pode ser baixado do URL.
Aponta para metadados sobre um documento e não para o próprio documento. Um exemplo de URC é aquele que aponta para o código-fonte HTML de uma página como:view-source:http://example.com/
Em vez de localizá-lo na Internet ou nomeá-lo, os dados podem ser colocados diretamente em um URI. Um exemplo seria data:,Hello%20World
.
A especificação W3 para HTML diz que a href
marca de uma âncora pode conter um URI, não apenas um URL. Você deve conseguir inserir um URN como <a href="urn:isbn:0451450523">
. Seu navegador resolveria esse URN para um URL e baixaria o livro para você.
Não que eu saiba, mas o navegador da Web moderno implementa o esquema de URI de dados.
Não. Os URLs relativos e absolutos são URLs (e URIs).
Não. Ambos os URLs com e sem parâmetros de consulta são URLs (e URIs).
Não. Ambos os URLs com e sem identificadores de fragmento são URLs (e URIs).
Não. Os URLs são definidos como um subconjunto estrito de URIs. Se um analisador permitir um caractere em um URL, mas não em um URI, haverá um erro no analisador. As especificações entram em detalhes sobre quais caracteres são permitidos em quais partes de URLs e URIs. Alguns caracteres podem ser permitidos apenas em algumas partes da URL, mas os caracteres por si só não fazem diferença entre URLs e URIs.
Sim. O W3C percebeu que há muita confusão sobre isso. Eles emitiram um documento de esclarecimento de URI que diz que agora não há problema em usar os termos URL e URI de forma intercambiável (para significar URI). Não é mais útil segmentar estritamente URIs em diferentes tipos, como URL, URN e URC.
A definição de URN agora é mais flexível do que o que afirmei acima. A RFC mais recente em URIs diz que qualquer URI agora pode ser um URN (independentemente de começar com urn:
) desde que tenha "as propriedades de um nome". Ou seja: é globalmente único e persistente, mesmo quando o recurso deixa de existir ou fica indisponível. Um exemplo: os URIs usados em doctypes HTML, como http://www.w3.org/TR/html4/strict.dtd
. Esse URI continuaria nomeando o tipo de documento de transição HTML4, mesmo que a página no site w3.org fosse excluída.
file://
prefixo nele. Embora os navegadores geralmente lidem com caminhos de arquivos não formatados em URL. A Mozilla publica seus casos de teste para URLs de arquivos .
mailto:user@example.com
como URL, mas outra resposta abaixo diz que é um URN? Qual é certo? É URN e URL?
Em resumo: um URI identifica, um URL identifica e localiza.
Considere uma edição específica da peça Romeu e Julieta de Shakespeare , da qual você tem uma cópia digital em sua rede doméstica.
Você pode identificar o texto como urn:isbn:0-486-27557-4
.
Isso seria um URI, mas mais especificamente um URN * porque nomeia o texto .
Você também pode identificar o texto como file://hostname/sharename/RomeoAndJuliet.pdf
.
Isso também seria um URI, mas mais especificamente um URL, porque ele localiza o texto .
* Nome uniforme do recurso
(Observe que meu exemplo é adaptado da Wikipedia )
ISBN 0486275574
também nomeia o texto e, portanto, se qualifica como URN. Eu escolho um formato que eu acreditava que seria mais familiar para os leitores.
Estas são algumas respostas muito bem escritas, mas muito longas. Aqui está a diferença no que diz respeito ao CodeIgniter :
URL - http://example.com/some/page.html
URI - /some/page.html
Simplificando, o URL é o caminho completo para identificar qualquer recurso em qualquer lugar e pode ter protocolos diferentes, como FTP, HTTP, SCP, etc.
O URI é um recurso no domínio atual, portanto, é necessário encontrar menos informações.
Em todos os casos em que o CodeIgniter usa a palavra URL ou URI, essa é a diferença da qual eles estão falando, embora no esquema geral da Web, isso não seja 100% correto.
/some/page.html
não é um URI. É um "parente-ref", que é um tipo de "referência de URI". Combinado com um contexto URI básico, ele pode ser resolvido para um URI, mas não é um URI. Veja a Seção 4.1 da RFC 3986 . O CodeIgniter provavelmente está usando os termos errados e isso deve ser chamado; o Q (como editado atualmente) não está enquadrado como específico do CodeIgniter.
Antes de tudo, tire sua mente da confusão e simplifique-a e você entenderá.
URI => Identificador Uniforme de Recursos Identifica um endereço completo do recurso, como local, nome ou ambos.
URL => Localizador uniforme de recursos Identifica a localização do recurso.
URN => Nome uniforme do recurso Identifica o nome do recurso
Exemplo
Temos o endereço https://www.google.com/folder/page.html em que,
URI (identificador uniforme de recursos) => https://www.google.com/folder/page.html
URL (Localizador uniforme de recursos) => https://www.google.com/
URN (Nome Uniforme do Recurso) => /pasta/page.html
URI => (URL + URN) ou apenas URL ou apenas URN
Uma pequena adição às respostas já postadas, aqui está um diagrama de Venn para resumir a teoria (da bela explicação de Prateek Joshi ):
E um exemplo (também do site da Prateek):
#posts
identificador de fragmento pode fazer parte da URL
Esse é um dos tópicos mais confusos e possivelmente irrelevantes que encontrei como profissional da web.
Pelo que entendi, um URI é uma descrição de algo, seguindo um formato aceito, que pode definir ambos ou o nome exclusivo (identificação) de algo e sua localização.
Existem dois subconjuntos básicos - URLs, que definem o local (especialmente para um navegador que tenta procurar uma página da web) e URNs, que definem o nome exclusivo de algo.
Costumo pensar em URNs como sendo semelhantes aos GUIDs. Eles são simplesmente uma metodologia padronizada para fornecer nomes exclusivos para as coisas. Como no declarativo de espaço para nome que usa o nome de uma empresa - não é como se houvesse um recurso em um servidor em algum lugar para corresponder a essa linha de texto - ele simplesmente identifica algo de forma exclusiva.
Eu também tendem a evitar completamente o termo URI e discutir as coisas apenas em termos de URL ou URN, conforme apropriado, porque isso causa muita confusão. A pergunta que realmente devemos tentar responder às pessoas não é tanto a semântica, mas como identificar, ao encontrar os termos, se existe alguma diferença prática neles que mudará a abordagem de uma situação de programação. Por exemplo, se alguém me corrige na conversa e diz: "oh, isso não é um URL, é um URI", eu sei que ele é cheio disso. Se alguém disser "estamos usando um URN para definir o recurso", é mais provável que entendamos que estamos apenas nomeando-o exclusivamente, não o localizando em um servidor.
Se eu estiver fora da base - por favor me avise!
redirect_url
vez de redirect_uri
, alguém realmente se importaria?
Identidade = Nome com Localização
Cada URL ( U niform R esource L ocator) é um URI ( U niform R esource I dentifier), abstratamente falando, mas cada URI não é uma URL. Há uma outra subcategoria da URI é URN ( U niform R esource N AME), que é um recurso nomeado, mas não especificar como localizá-los, como mailto, notícias, ISBN é URIs. Fonte
URNA:
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
URL:
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
Analogia:
Para alcançar uma pessoa: Dirigir (protocolo outros SMS, email, telefone), Endereço (nome do host outro número de telefone, emailid) e nome da pessoa (nome do objeto com um caminho relativo).
URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
URLs são um subconjunto de URIs (que também contêm URNs).
Basicamente, um URI é um identificador geral, em que um URL especifica um local e um URN especifica um nome.
[
e ]
não um URI.
Outro exemplo que eu gosto de usar quando penso em URIs é o atributo xmlns de um documento XML:
<rootElement xmlns:myPrefix="com.mycompany.mynode">
<myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>
Nesse caso, com.mycompany.mynode seria um URI que identifica exclusivamente o espaço de nome "myPrefix" para todos os elementos que o usam no meu documento XML. Este NÃO é um URL, pois é usado apenas para identificar, não para localizar algo em si.
Devido a dificuldades em distinguir claramente entre URI e URL, tanto quanto me lembro, o W3C não faz mais diferença entre URI e URL ( http://www.w3.org/Addressing/ ).
Eles são a mesma coisa . Um URI é uma generalização de um URL. Originalmente, os URIs eram planejados para serem divididos em URLs (endereços) e URNs (nomes), mas havia pouca diferença entre um URL e os URIs e os URLs http eram usados como espaços de nome, mesmo que eles não localizassem realmente nenhum recurso.
URI, URL, URN
Como a imagem acima indica, existem três componentes distintos em jogo aqui. Geralmente, é melhor ir à fonte ao discutir assuntos como esses, então, aqui está um esforço de Tim Berners-Lee, et. al. no RFC 3986: URI (Uniform Resource Identifier): Sintaxe genérica:
Um URI (Uniform Resource Identifier) é uma sequência compacta de caracteres que identifica um recurso abstrato ou físico.
Um URI pode ainda ser classificado como localizador, nome ou ambos. O termo "URL (Uniform Resource Locator") refere-se ao subconjunto de URIs que, além de identificar um recurso, fornece um meio de localizar o recurso, descrevendo seu mecanismo de acesso primário (por exemplo, sua "localização" da rede).
URI é o tipo da super classe de URLs e URNs. A Wikipedia tem um bom artigo sobre eles, com links para o conjunto certo de RFCs.
A Wikipedia fornecerá todas as informações que você precisa aqui. Citando http://en.wikipedia.org/wiki/URI :
Um URL é um URI que, além de identificar um recurso, fornece meios de agir sobre ou obter uma representação do recurso, descrevendo seu mecanismo de acesso primário ou "local" da rede.
URL
Uma URL é uma especialização de URI que define o local da rede de um recurso específico. Ao contrário de um URN, o URL define como o recurso pode ser obtido. Usamos URLs todos os dias na forma de http://example.com
etc. Mas uma URL não precisa ser uma URL HTTP, pode ser ftp://example.com
etc. também.
URI
Um URI identifica um recurso por local ou nome ou ambos. Na maioria das vezes, a maioria de nós usa URIs que definem um local para um recurso. O fato de um URI poder identificar recursos por nome e local levou a muita confusão na minha opinião. Um URI tem duas especializações conhecidas como URL e URN.
Diferença entre URL e URI
Um URI é um identificador para algum recurso, mas um URL fornece informações específicas sobre como obter esse recurso. Um URI é uma URL e, como um comentarista apontou, agora é considerado incorreto usar a URL ao descrever aplicativos. Geralmente, se o URL descreve o local e o nome de um recurso, o termo a ser usado é URI. Como geralmente é o caso que a maioria de nós encontra todos os dias, URI é o termo correto.
Conforme a RFC 3986 , os URIs são compostos pelas seguintes partes:
scheme://authority/path?query
O URI descreve o protocolo para acessar um recurso ( caminho ) ou aplicativo ( consulta ) em um servidor ( autoridade ).
Todos os URLs são URIs e todos os URNs são URIs, mas todos os URIs não são URLs.
Consulte para mais detalhes:
Um URI identifica um recurso por local ou nome ou ambos. Na maioria das vezes, a maioria de nós usa URIs que definem um local para um recurso. O fato de um URI poder identificar recursos por nome e local levou a muita confusão na minha opinião. Um URI tem duas especializações conhecidas como URL e URN.
Uma URL é uma especialização de URI que define o local da rede de um recurso específico. Ao contrário de um URN, o URL define como o recurso pode ser obtido. Usamos URLs todos os dias na forma de http://stackoverflow.com , etc. Mas uma URL não precisa ser uma URL HTTP, pode ser ftp://example.com
, etc.
Embora os termos URI e URL sejam estritamente definidos, muitos usam os termos para outras coisas além das definidas.
Vamos pegar o Apache por exemplo. Se http://example.com/foo for solicitado em um servidor Apache, você terá as seguintes variáveis de ambiente definidas:
REDIRECT_URL
: /foo
REQUEST_URI
: /foo
Com mod_rewrite ativado, você também terá estas variáveis:
REDIRECT_SCRIPT_URL
: /foo
REDIRECT_SCRIPT_URI
: http://example.com/foo
SCRIPT_URL
: /foo
SCRIPT_URI
: http://example.com/foo
Este pode ser o motivo de algumas das confusões.
Veja este documento . Especificamente,
uma URL é um tipo de URI que identifica um recurso por meio de uma representação de seu mecanismo de acesso primário (por exemplo, sua "localização" da rede)), e não por outros atributos que possa ter.
Não é um termo extremamente claro, realmente.
Depois de ler as postagens, encontro alguns comentários muito relevantes. Em resumo, a confusão entre as definições de URL e URI é baseada em parte em qual definição depende de qual e também no uso informal da palavra URI no desenvolvimento de software.
Por definição, o URL é um subconjunto do URI [RFC2396]. URI contém URN e URL. Tanto o URI quanto o URL têm sua própria sintaxe específica, que confere a eles o status de URI ou URL. URN são para identificar exclusivamente um recurso, enquanto o URL é para localizar um recurso. Observe que um recurso pode ter mais de um URL, mas apenas um único URN. [RFC2611]
Como desenvolvedores e programadores da Web, quase sempre nos preocupamos com URL e, portanto, com URI. Agora, um URL é definido especificamente para ter todo o esquema de partes: parte específica do esquema, como por exemplo https://stackoverflow.com/questions . Este é um URL e também é um URI. Agora considere um link relativo incorporado à página, como ../index.html. Este não é mais um URL por definição. Ainda é o que é chamado de "referência de URI" [RFC2396].
Acredito que quando a palavra URI é usada para se referir a caminhos relativos, "referência de URI" é realmente o que está sendo pensado. Tão informalmente, os sistemas de software usam o URI para se referir ao caminho relativo e à URL do endereço absoluto. Portanto, nesse sentido, um caminho relativo não é mais uma URL, mas ainda é um URI.
Aqui está a minha simplificação:
URN: nome exclusivo do recurso, ou seja, "o quê" (por exemplo, urn: issn: 1234-5678). Isso deve ser único. Como em dois documentos diferentes, a mesma urna não pode ser usada. Um pouco como "uuid"
URL: "onde" para encontrá-lo (por exemplo, https://google.com/pub?issnid=1234-5678 .. ou ftp://somesite.com/doc8.pdf )
URI: pode ser um URN ou um URL. Esta definição difusa é graças ao RFC 3986 produzido pelo W3C e IETF.
A definição de URI mudou ao longo dos anos, por isso faz sentido que a maioria das pessoas fique confusa. No entanto, agora você pode se consolar com o fato de poder consultar http://somesite.com/something como URL ou URI ... e você estará certo de qualquer maneira (pelo menos por enquanto). .)
Eu estava pensando sobre a mesma coisa e encontrei o seguinte: http://docs.kohanaphp.com/helpers/url .
Você pode ver um exemplo claro usando o url::current()
método Se você tiver este URL : o http://example.com/kohana/index.php/welcome/home.html?query=string
uso url:current()
fornece o URI que, de acordo com a documentação, é: bem - vindo / home
Os URIs surgiram da necessidade de identificar recursos na Web e outros recursos da Internet , como caixas de correio eletrônicas, de maneira uniforme e coerente. Portanto, pode-se introduzir um novo tipo de widget: URIs para identificar recursos do widget ou usar tel: URIs para ter links da Web, fazendo com que chamadas telefônicas sejam feitas quando invocadas.
Alguns URIs fornecem informações para localizar um recurso (como um nome de host DNS e um caminho nessa máquina), enquanto outros são usados como nomes de recursos puros. A URL é reservada para identificadores que são localizadores de recursos , incluindo URLs 'http' como http://stackoverflow.com , que identifica a página da web no caminho especificado no host. Outro exemplo são os URLs 'mailto', como mailto: fred@mail.org , que identifica a caixa de correio no endereço fornecido.
URNs são URIs usados como nomes puros de recursos em vez de localizadores. Por exemplo, o URI: mid: 0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.com é um URN que identifica a mensagem de email que a contém em seu campo 'Message-Id'. O URI serve para distinguir essa mensagem de qualquer outra mensagem de email. Mas ele próprio não fornece o endereço da mensagem em nenhuma loja.
Para responder a isso, vou me basear em uma resposta que eu modifiquei para outra pergunta . Um bom exemplo de um URI é como você identifica um recurso do Amazon S3. Vamos levar:
s3://www-example-com/index.html
[FIG. 1]
que eu criei como uma cópia em cache de
http://www.example.com/index.html
[FIG. 2]
no datacenter S3-US-West-2 da Amazon .
Mesmo que o StackOverflow me permita vincular ao esquema de s3://
protocolo , não ajudaria em localizar o recurso. Porque identifica um recurso , fig. 1 é um URI válido. Também é um URN válido, porque a Amazon exige que o bucket (seu termo para a authority
parte do URI) seja exclusivo entre os datacenters. É útil localizá-lo, mas não indica o datacenter. Portanto, ele não funciona como um URL.
Então, como o URI, URL e URN diferem nesse caso?
NOTA: O RFC 3986 define URIs comoscheme://authority/path?query#fragment
Fácil de explicar:
Vamos assumir o seguinte
URI é o seu nome
URL é o seu endereço com o seu nome para se comunicar com você.
meu nome é Loyola
Loyola é URI
meu endereço é TN, Chennai 600001.
TN, Chennai 600 001, Loyola é URL
Espero que você entenda,
Agora vamos ver um exemplo preciso
http://www.google.com/fistpage.html
acima, você pode se comunicar com uma página chamada firstpage.html ( URI ) usando o seguinte http://www.google.com/fistpage.html ( URL ).
Portanto, o URI é um subconjunto de URL, mas não vice-versa.
Um URI (Uniform Resource Identifier) é uma sequência de caracteres que identifica um Recurso na Internet.
O URI mais comum é o URL (Uniform Resource Locator) que identifica um endereço de domínio da Internet. Outro tipo de URI não tão comum é o Universal Resource Name (URN).
Eu encontrei:
Um identificador de recurso uniforme (URI) representa uma imagem geral. Você pode dividir URIs / URIs podem ser classificados como localizadores (URLs), ou como nomes (URLs), ou ambos. Então, basicamente, um URN funciona como o nome de uma pessoa e o URL representa o endereço dessa pessoa. Para encurtar a história, um URN define a identidade de um item, enquanto o URL fornece o método para encontrá-lo, e finalmente encapsular esses dois conceitos é o URI
O melhor resumo técnico ( imo) é este
IRI, URI, URL, URN e suas diferenças relação a Jan Martin Keil:
Todo mundo que lida com a Web Semântica repetidamente se depara com os termos IRI , URI , URL e URN . No entanto, frequentemente observo que há alguma confusão sobre o significado exato deles. E, é claro, outros notaram isso também (veja, por exemplo, RFC3305 ou pesquise no Google). Para ser sincero, eu até me confundi desde o início. Mas, na verdade, a questão não é tão complexa. Vamos dar uma olhada nas definições dos termos mencionados para ver quais são as diferenças:
Um identificador uniforme de recursos é uma sequência compacta de caracteres que identifica um recurso abstrato ou físico. O conjunto de caracteres é limitado a US-ASCII, excluindo alguns caracteres reservados. Caracteres fora do conjunto de caracteres permitidos podem ser representados usando a Porcentagem de Codificação. Um URI pode ser usado como localizador, nome ou ambos. Se um URI é um localizador, ele descreve o mecanismo de acesso primário de um recurso. Se um URI é um nome, ele identifica um recurso, fornecendo a ele um nome exclusivo. As especificações exatas de sintaxe e semântica de um URI dependem do esquema usado que é definido pelos caracteres antes dos primeiros dois pontos. [RFC3986]
Um Nome Uniforme de Recurso é um URI no urn do esquema destinado a servir como identificador de recurso persistente e independente de local. Historicamente, o termo também se referia a qualquer URI. [RFC3986] Um URN consiste em um NID (Namespace Identifier) e uma NSS (String) específica de namespace: urn :: A sintaxe e a semântica do NSS são específicas para cada NID. Além dos DNIs registrados, existem vários outros DNIs, que não passaram pelo processo de registro oficial. [RFC2141]
Um Uniform Resource Locator é um URI que, além de identificar um recurso, fornece um meio de localizar o recurso, descrevendo seu mecanismo de acesso primário [RFC3986]. Como não existe uma definição exata de URL por meio de um conjunto de esquemas, "URL é um conceito útil, mas informal", geralmente se referindo a um subconjunto de URIs que não contêm URNs [RFC3305].
Um identificador de recurso internacionalizado é definido de maneira semelhante a um URI, mas o conjunto de caracteres é estendido ao conjunto de caracteres codificados universal. Portanto, ele pode conter caracteres latinos e não latinos, exceto os caracteres reservados. Em vez de estender a definição de URI, o termo IRI foi introduzido para permitir uma distinção clara e evitar incompatibilidades. Os IRIs destinam-se a substituir os URIs na identificação de recursos em situações nas quais o Conjunto Universal de Caracteres Codificados é suportado. Por definição, todo URI é um IRI. Além disso, existe um mapeamento adjetivo definido de IRIs para URIs: todo IRI pode ser mapeado para exatamente um URI, mas diferentes IRIs podem ser mapeados para o mesmo URI. Portanto, a conversão de volta de um URI para um IRI pode não produzir o IRI original. [RFC3987]
IRI is a superset of URI (IRI ⊃ URI)
URI is a superset of URL (URI ⊃ URL)
URI is a superset of URN (URI ⊃ URN)
URL and URN are disjoint (URL ∩ URN = ∅)
RDF permite explicitamente usar IRIs para nomear entidades [RFC3987]. Isso significa que podemos usar quase todos os caracteres nos nomes de entidades. Por outro lado, geralmente temos que lidar com o software do estado inicial. Portanto, é improvável que haja problemas usando caracteres não ASCII. Portanto, sugiro evitar nomes não URI para entidades e recomendo o uso de http URIs [LINKED-DATA]. Para resumir: use apenas URLs para nomear suas entidades. Obviamente, podemos nos referir a entidades existentes nomeadas por uma URN. No entanto, devemos evitar criar recentemente esse tipo de identificador.