Identificazione di Risorse nel Semantic Web

IDENTIFICAZIONE DI RISORSE NEL SEMANTIC WEB
Versione 0.1 - 6/4/2006
Di Daniele Alessandrelli
[email protected]
SEMEDIA
Semantic Web and Multimedia Group
http://semedia.deit.univpm.it
I linguaggi del Semantic Web come RDF e OWL necessitano di un mezzo per identificare in modo
univoco le risorse oggetto di informazione: tale mezzo sono gli URI. In questo tutorial si
approfondisce il concetto di URI spiegandone il significato e descrivendone brevemente la sintassi
generica. Saranno inoltre presentati e descritti alcuni “tipi” di URI largamente utilizzati nel
Semantic Web.
1.URI
URI è l'acronimo di Uniform Resource Identifier, la cui traduzione letterale è identificatore
uniforme di risorsa.
Con il termine identificatore si indica un qualcosa che permette di distinguere un particolare oggetto
(l'oggetto identificato appunto) da tutti gli altri all'interno di un determinato insieme. Tale insieme
può anche essere l'insieme contenente tutti i possibili oggetti, nel qual caso si dice che
l'identificatore ha scope globale. È importante sottolineare che gli URI, in quanto identificatori, non
devono necessariamente fornire accesso all'oggetto identificato.
Con l'aggettivo uniforme ci si riferisce alla proprietà di uniformità degli URI. Tale proprietà
fornisce diversi benefici. Essa permette di usare nello stesso contesto differenti tipi di URI, anche
nel caso in cui i meccanismi per accedere alle risorse identificare siano diversi tra loro. Permette,
inoltre, un'interpretazione uniforme tra i vari tipi di URI della semantica associata a certe
convenzioni sintattiche. Garantisce la possibilità di introdurre un nuovo tipo di URI senza interferire
con il modo in cui gli identificatori esistenti sono utilizzati. Permette, infine, il riutilizzo degli
identificatori in contesti diversi da quello in cui sono stati creati premettendo a nuove applicazioni o
protocolli di sfruttare un insieme preesistente di identificatori ampio e largamente utilizzato.
1
La definizione di URI non pone vincoli su cosa possa essere una risorsa; il termine risorsa è usato in
senso generale per indicare qualunque cosa possa essere identificata da un URI. Si possono
catalogare le risorse in tre diversi tipi:
•
quelle accessibili in rete, come documenti elettronici, immagini, servizi, ecc.
•
quelle non accessibili in rete, come gli esseri umani, le società, i libri, ecc.
•
i concetti astratti che non esistono fisicamente, come ad esempio il concetto di “autore”.
1.1 Relazione con URL e URN
Un URI può essere classificato o come un indirizzo (URL) o come un nome (URN) o come
entrambi.
Un URL (Uniform Resource Locator) è un particolare tipo di URI che, oltre ad identificare una
risorsa, fornisce un metodo per localizzarla specificando il suo principale metodo di accesso. Per
esempio l'URL http://www.w3c.org/ identifica l'homepage del W3C e al tempo stesso indica che
una rappresentazione di tale risorsa (il codice HTML dell'homepage) può essere ottenuta tramite il
protocollo HTTP dall'host chiamato www.w3c.org .
Un URN (Uniform Resource Name) è un URI che identifica una risorsa per mezzo di un nome
appartenente ad un particolare namespace. Un URN può essere usato per riferirsi ad una risorsa
senza indicare dove essa si trovi o come sia possibile ottenerne una rappresentazione
(dereferenziarla). Ad esempio l'URN urn:isbn:0-06-251586-1 è un URI che permette di riferirsi
ad un particolare libro senza indicare dove e come sia possibile recuperarne una copia.
1.2 Sintassi
Un URI è in pratica una stringa avente la seguente sintassi [1]:
URI = scheme “:” scheme-specific-part
Ogni URI comincia con la parte scheme contenente il nome di un URI scheme. Un URI scheme è
una schema che definisce le specifiche per assegnare identificatori all'interno di tale schema. Le
specifiche di ciascuno schema definiscono la sintassi e la semantica degli identificatori che usano
tale schema. La parte scheme è seguita dai “:” e dalla parte scheme-specific la cui struttura è,
appunto, definita dall'URI scheme usato.
La sintassi è dunque organizzata in modo gerarchico, con i vari componenti disposti in ordine
decrescente di significato da sinistra a destra. Per alcuni URI scheme la visibilità di tale gerarchia è
limitata allo schema stesso: tutto ciò che segue i due punti (che delimitano lo schema) è considerato
opaco per il processamento dell'URI. Altri schemi rendono invece la gerarchia esplicita e visibile
permettendo l'uso di algoritmi generici di suddivisione dell'URI nei suoi componenti.
La sintassi generica usa i caratteri slash “/”, punto interrogativo “?” e cancelletto “#” per delimitare
2
tali componenti, che sono, oltre allo scheme, l'authority, il path, il query ed il fragment.
La sintassi generica di un URI è dunque la seguente:
URI = scheme “:” [ “//” authority ] path [ “?” query ] [ “#” fragment ]
1.2.1 Scheme
Il significato di tale elemento è già stato visto. Per quanto riguarda la sua sintassi va invece detto
che esso è case-insensitive, ma la forma canonica è in minuscolo e dunque è raccomandato che
applicazioni che generano URI usino scheme scritti in minuscolo.
1.2.2 Authority
Molti URI scheme includono un elemento gerarchico (opzionale) che identifica un naming
authority al quale è delegato il controllo del namespace definito dal resto dell'URI.
Il componente authority è delimitato da uno slash “/”, un punto interrogativo “?”, dal cancelletto
“#” o dalla fine dell'URI.
1.2.3 Path
Il componente path (obbligatorio) contiene dei dati, generalmente organizzati in forma gerarchica,
che insieme ai dati contenuti nel componente query permettono di identificare una risorsa
all'interno dello scope dell'URI scheme e del naming authority (se presente). Il componente path è
terminato dal primo punto interrogativo “?” o cancelletto “#” o dalla fine dell'URI. Il componente
path, sebbene obbligatorio, può essere vuoto, ma solo se il componente authority non lo è.
1.2.4 Query
Il componente query (opzionale) contiene dati non gerarchici che, assieme a quelli del componente
path permettono di identificare una risorsa all'interno dello scope dell'URI scheme e del naming
authority (se presente). L'inizio del componente query è indicato dal primo punto interrogativo “?”
mentre la fine è indicata dal primo cancelletto “#” o dalla fine dell'URI.
1.2.5 Fragment Identifier
Il componente fragmet (opzionale) permette un'identificazione indiretta di una risorsa secondaria
per mezzo del riferimento alla risorsa primaria (identificata dell'URI privato del fragment) e di
ulteriori dati identificativi. La risorsa secondaria può essere una porzione o un sottogruppo di quella
primaria o può essere un'altra risorsa definita o descritta dalla risorsa primaria.
1.3 URI nel Semantic Web
Gli URI svolgono un ruolo fondamentale nel Semantic Web (non a caso si trovano nel primo strato
3
della “semantic cake”1). Permettono infatti di identificare in modo univoco e globale una risorsa di
cui vogliamo parlare. L'RDF si basa sull'ipotesi che due risorse aventi lo stesso URI 2 siano la stessa
risorsa, ovvero che un URI identifichi una ed una sola risorsa. Dunque le triple relative ad uno
stesso URI, ma contenute in documenti diversi possono essere aggregate. Viene eliminata
l'ambiguità del linguaggio comune in cui una stessa parola o uno stesso nome possono essere usati
per indicare due concetti diversi.
Storicamente gli URI nascono per identificare risorse web [2]; per tali risorse esistono dunque dei
ben noti metodi per associarvi URI. Con la nascita del Semantic Web, il loro uso è stato esteso a
tutte le risorse, ciò pone però il problema di come assegnare URI a risorse fisiche o concettuali.
Qual è l'URI di un'automobile? E quella di persona? E quella del concetto di pace?
Tale problema è stato risolto principalmente in due modi: estendendo l'uso di URI scheme già
esistenti e creando nuovi URI scheme utilizzabili per qualunque risorsa.
2.Uso di URI con schema http
L'URI scheme http [3] è probabilmente lo schema più noto ed utilizzato nel Web attuale. Fu ideato
per identificare risorse web accessibili tramite il protocollo HTTP (HyperText Transfer Protocol).
Gli URI http hanno la seguente sintassi (che rispetta quella generica precedentemente descritta):
http URI = “http://” host [ port ] [ “/” path ] [ “?” query ] [ “#” fragment ]
Come si può vedere il ruolo dell'elemento authority della sintassi generica è svolto dall'elemento
host; esso identifica un particolare computer per mezzo o del suo IP o più frequentemente del suo
nome. Per computer connessi ad Internet tale nome è composto dal loro hostname e da un nome di
dominio. Questi ultimi sono assegnati in modo centralizzato da apposite organizzazioni che
garantiscono che ogni nome di dominio sia assegnato ad un'unica entità (persona, società,
organizzazione, ecc.). Dunque chi possiede un nome di dominio può creare URI http
semplicemente scegliendo il path che ritiene opportuno per la risorsa che vuole identificare. A
seguito di questa facilità nel creare URI, della sua ampia diffusione e della iniziale mancanza di
URI scheme adatti per qualunque risorsa, lo schema http è stato ed è tuttora usato nel Semantic
Web per identificare, non solo risorse web accessibili tramite HTTP, ma anche risorse fisiche e
concetti. Ad esempio il proprietario del dominio example.org potrebbe usare l'URI
http://www.example.org/mycat per identificare il proprio gatto. Egli potrebbe inoltre collocare a
tale URL un documento elettronico (testo in linguaggio naturale, immagine, ecc.) che descriva la
risorsa identificata, in questo caso il suo gatto. Questo metodo è ampiamente usato nel Semantic
Web, in quanto permette di capire quale sia la risorsa identificata da un determinato URI
1 http://www.w3.org/2000/Talks/1206-xml2k-tbl/slide10-0.html
2 L'RDF considera due URI lo stesso URI solamente se sono uguali carattere per carattere.
4
semplicemente dereferenziandolo.
L'uso dello schema http presenta dunque vari vantaggi, tuttavia esso soffre di un problema di
notevole rilevanza, quello dell'URI crisis [4] [5].
2.1 URI Crisis
L'URI crisis si manifesta quando usiamo un URI del tipo http per identificare delle risorse fisiche o
dei concetti. In questo caso infatti l'URI può essere anche utilizzato per identificare il documento
che si trova all'URL corrispondente. Abbiamo dunque un URI che può identificare due risorse.
Questo problema può essere risolto in due modi, o attraverso l'uso del fragment identifier o tramite
un'apposita configurazione del server web che risponde alla richiesta di GET causata dal tentativo
di dereferenziare l'URI.
2.2 Uso del fragment identifier
Una semplice soluzione al problema dell'URI crisis consiste nell'aggiungere all'URL della pagina
che descrive la risorsa fisica o il concetto, un fragment identifier vuoto. L'URI dell'esempio
precedente, usato dal proprietario di example.org per identificare il proprio gatto, diventerebbe
dunque http://www.example.org/mycat#. Dereferenziando tale URI si ottiene comunque la
descrizione della risorsa identificata, pur avendo due URI diversi, uno per la risorsa ed uno per il
documento che la descrive.
Nel caso si abbiano più risorse da identificare, invece di creare un documento descrittivo per
ognuna di esse, si potrebbero aggregare in un unico documento le diverse descrizioni ed usare come
URI per le risorse l'URL del documento seguito da un fragment identifier contenente il nome della
risorsa. Ad esempio supponendo che il proprietario di example.org abbia due gatti, Tom e
Silvestro, egli potrebbe identificarli usando gli URI http://www.example.org/mycats#Tom e
http://www.example.org/mycats#Silvestro
e
potrebbe
collocare
all'URL
http://www.example.org/mycats una loro foto o un altro documento che li descrive.
2.3 Provare a dereferenziare l'URI
Per quanto riguarda gli URI http privi di fragment identifier il TAG (Technical Architecture Group)
ha stabilito che per determinare il tipo di risorsa da essi identificata, bisogna provare a
dereferenziare l'URI, eseguendo un richiesta di GET per esso, e verificare quale status code viene
restituito dal web server [6] :
•
se si ottiene un codice 2xx allora la risorsa identificata è una risorsa web
•
se si ottiene un codice 303 (See Other) allora la risorsa identificata può essere qualunque tipo
di risorsa
5
•
se si ottiene un codice 4xx (Error) allora la natura della risorsa è sconosciuta
Di conseguenza per utilizzare un URI http privo di fragment identifier per identificare una risorsa
reale si deve configurare il proprio web server in modo tale che risponda ad una richiesta di GET
per quell'URI con un redirect su un altro URL al quale si può collocare una descrizione della risorsa
identificata.
2.3.1 PURL
In alternativa alla suddetta configurazione del proprio server web, si può utilizzare il servizio
PURL3 [7] messo a disposizione dall'Online Computer Library Center. PURL sta per Persistent
Uniform Resource Locator; si tratta essenzialmente di un URL che invece di puntare direttamente
ad un risorsa sul Web punta ad un sistema di risoluzione intermedio. Il sistema di risoluzione PURL
associa il PURL con l'effettivo URL della risorsa e restituisce tale URL al client che esegue una
richiesta di GET sul PURL. Questo avviene tramite un HTTP redirect.
3.URN – Uniform Resource Names
Il concetto di URN è già stato introdotto, ora si vedrà più in dettaglio quali sono i requisiti che un
URI deve rispettare per poter essere considerato un URN.
Lo scopo di un URN è quello di fornire un identificatore globalmente univoco e persistente usato
per riconoscere una risorsa ed eventualmente accedere alle sue caratteristiche o accedere alla risorsa
stessa.
Sebbene sia stato definito un URI scheme specifico per la creazione di URN, lo schema urn, anche
URI che utilizzano un altro schema posso essere classificati come URN, è infatti sufficiente che essi
rispettino i seguenti requisiti funzionali [8]:
•
Scope globale: un URN è un nome con scope globale che non implica una collocazione. Ha lo
stesso significato ovunque.
•
Univocità globale: lo stesso URN non sarà mai assegnato a due diverse risorse.
•
Persistenza: la vita di un URN è permanente. Ovvero sarà globalmente univoco per sempre e
può essere usato come identificativo di una risorsa per un periodo maggiore della vita stessa
della risorsa o della naming authority coinvolta nella sua assegnazione.
•
Scalabilità: gli URN possono essere assegnati a risorse che saranno plausibilmente disponibili
per migliaia di anni.
•
Supporto di sistemi di nomenclatura legacy: lo schema deve supportare sistemi di
nomenclatura già esistenti purché essi rispettino gli altri requisiti qui descritti.
•
Estensibilità: ogni schema per URN deve permettere future estensioni.
3 http://www.purl.org/
6
•
Indipendenza: è compito esclusivo dell'autorità che genera il nome determinare le condizioni
sotto le quali generare un nome.
•
Risoluzione: un URN non impedirà la risoluzione (trasformazione in URL). In particolare per
URN che hanno un corrispondente URL deve esistere un meccanismo per ottenerlo.
Lo schema urn permette di creare URI utilizzando nomi appartenenti a particolari namespace che
rispettano i requisiti suddetti. La sintassi di un URI con schema urn è la seguente:
URN = "urn:" NID ":" NSS
l'elemento NID (namespace identifier) identifica un particolare namespace, mentre l'elemento NSS
(namespace specific) contiene una stringa che permette di identificare in modo univoco una risorsa
all'interno del namespace considerato.
Esempi di URN sono i seguenti:
•
urn:isbn:0451450523
•
urn:ietf:rfc:3187
•
urn:oid:2.16.840
3.1 duri e tdb
duri e tdb [9] sono due urn namespace che permettono di creare in modo agevole degli URN per
identificare documenti e risorse fisiche o concetti.
La sintassi del namespace duri è la seguente:
DURI = "urn:duri:" date ":" encoded-URI
dove date è un stringa di numeri corrispondente ad una data, mentre encoded-URI è un URI
assoluto in cui tutti i caratteri, esclusi quelli appartenenti alla sintassi urn, sono stati escapati.
Il significato di un duri è la risorsa che era identificata dall'encoded-URI (decodificato) nell'istante
di tempo identificato dalla data. Per esempio l'URI urn:duri:2001:http://www.ietf.org è un
identificatore persistente del documento identificato da http://www.ietf.org all'inizio dell'anno
2001.
La sintassi del namespace tdb è analoga:
TDB = "urn:tdb:" date ":" "encoded-URI"
Il significato di un tdb (thing described by) è la risorsa descritta dal documento identificato
dall'encoded-URI nella data date. Il namespace tdb permette di identificare entità, concetti,
astrazioni o altre risorse che non sono esse stesse accessibili in rete, ma che in una certa data sono
state
descritte
da
una
risorsa
accessibile
in
rete.
Ad
esempio
l'URI
urn:tdb:2001:http://www.ietf.org identifica l'organizzazione Internet Engineering Task Force così
come era descritta dalla propria homepage all'inizio del 2001.
7
3.1.1 Risoluzione di duri e tdb
Non esiste un server che permetta un'accurata risoluzione di URN duri e tdb. Un duri può essere
“risolvibile” nel senso che è possibile accedere alla risorsa identificata dall'encoded-URI nella data
specificata tramite una cache o un qualche servizio di archivio Internet (come ad esempio
http://www.archive.org ). Un tdb è risolvibile nel senso che, se il corrispondente duri è risolvibile, è
possibile accedere al risultato di tale risoluzione ed interpretarlo.
Se non è possibile accedere a nessuna forma di archivio, si può cercare di risolvere l'encoded-URI
ottenendo il documento attualmente identificato. Ciò permette di ottenere un'approssimazione della
risoluzione del duri (o del tdb) la cui affidabilità dipende dal tempo trascorso dalla data indicata e
quella in cui avviene la risoluzione dell'encoded-URI.
4.TAG URI
I tag URI (URI con schema tag) [10] sono progettati per essere univoci nel tempo e nello spazio.
Essi si distinguono da molti degli altri tipi di URI per il fatto di non avere un meccanismo di
risoluzione autoritativo. Un tag URI può essere usato soltanto come identificatore.
I tag URI rispettano i seguenti requisiti:
•
Sono univoci nel tempo e nello spazio e ve ne è una disponibilità praticamente inesauribile.
•
È pratico per gli esseri umani crearli, leggerli, scriverli, ricordarli, ecc.
•
Non è richiesta una registrazione centralizzata, almeno per i possessori di domini o indirizzi
email; il “costo” per creare ciascun nuovo tag URI è irrisorio.
•
Sono indipendenti da qualsiasi particolare schema di risoluzione.
4.1 Sintassi
La sintassi di un tag URI è la seguente:
TAG URI = “tag:” taggingEntity “:” specific [ “#” fragment ]
Il componente taggingEntity definisce il namespace; la sua sintassi è la seguente:
authorityName “,” date
Il sotto-componente authorotyName può essere o un nome di dominio o un indirizzo email di
proprietà del creatore del tag URI. Il sotto-componente date è una data espressa nella forma
YYYY-MM-DD; date del tipo YYYY-MM-01 possono assere abbreviate nella forma YYYY-MM
ovvero indicando solo l'anno ed il mese, analogamente date del tipo YYYY-01-01 possono essere
abbreviate nella forma YYYY ovvero indicando semplicemente l'anno. La data specifica, secondo il
calendario gregoriano, un particolare giorno in cui l'authorityName era assegnato al creatore del
tag URI.
8
La coppia authorityName e date permette di identificare in modo univoco l'entità che crea il tag
URI; questo poiché in un determinato istante un dominio o un indirizzo email possono essere
assegnati ad una sola persona. Il solo authorityName non è sufficiente poiché un dominio o un
indirizzo email possono, nel tempo, cambiare proprietario.
La parte specific è la parte dipendente dal namespace: in pratica è una stringa, formata dai caratteri
permessi in un URI, scelta dal creatore dell'URI. È raccomandato che la parte specifica sia userfriendly.
I tag URI possono opzionalmente terminare con un fragment identifier.
Come detto il creatore del tag URI può scegliere liberamente la parte successiva al taggingEntity
(parte specific e fragment), tuttavia deve garantire la sua univocità. Se tale vincolo è rispettato il
tag URI generato sarà univoco (grazie al fatto che il taggingEntity, per come deve essere costruito,
è sempre univoco).
Esempi di tag URI sono i seguenti:
•
tag:[email protected],2001:web/externalHome
•
tag:[email protected],2004-05:Sandro
•
tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19
•
tag:blogger.com,1999:blog-555
•
tag:yaml.org,2002:int
5.Identificazione tramite valore di una IFP
Una IFP (Inverse Functional Property) è una proprietà i cui singoli valori possono essere riferiti al
massimo ad una risorsa, ovvero non possono esistere due soggetti diversi che abbiano, per tale
proprietà, lo stesso valore.
Come conseguenza di ciò si ha che in ogni statement avente come predicato tale proprietà, il
soggetto è univocamente determinato dall'oggetto (valore della proprietà). La coppia IFP e oggetto
può dunque essere usata per identificare il soggetto, sostituendo il compito svolto da un URI.
Questa soluzione viene spesso usata in RDF per quelle risorse per le quali non esiste un URI
standard o per le quali risulta difficile o troppo oneroso crearne una. Un esempio di applicazione
che utilizza tale metodo è il progetto FOAF.
5.1 Il progetto Friend of a Friend (FOAF)
Il progetto FOAF4 (Friend of a Friend) [11] si prefigge l'obiettivo di creare un Web in cui le pagine
che descrivono delle persone e i collegamenti tra esse e ciò che fanno o creano siano interpretabili
dalle macchine.
4 http://www.foaf-project.org/
9
FOAF è sostanzialmente un vocabolario RDF. Il suo uso tipico è simile a quello dell'RSS: il
proprietario di un sito crea uno o più file FOAF sul proprio web server e rende noti gli URL di tali
file cosicché appositi agenti software possano usare l'informazione in essi contenuta. Così come la
creazione di una pagina web, anche la creazione di dati FOAF è decentralizzata e sotto il controllo
dell'autore. Un esempio di applicazione che utilizza questi file è un archivio in cui i membri di una
comunità conservano i propri dati. Tuttavia, come con l'RSS, il progetto FOAF diviene molto
interessante quando i dati sono aggregati e possono essere esaminati e messi in relazione tra loro.
Il progetto FOAF ha dovuto affrontare il problema di creare un identificatore che permettesse di
riferirsi in modo univoco ad una persona. Questo problema viene risolto nei sistemi chiusi
assegnando ad ogni persona un identificatore specifico per quella determinata applicazione.
Tuttavia nel caso di FOAF si è in un sistema aperto in cui si vuole usare lo stesso identificatore per
servizi diversi, dunque la questione è più complicata. Una possibile soluzione sarebbe stata quella di
ricorrere ad un sistema centralizzato per controllare l'assegnazione delle identità, qualcosa di simile
a Microsoft Passport. Tuttavia un sistema centralizzato è rischioso per numerosi motivi, non ultimo
il fatto di affidare ad una terza parte il controllo sui propri accessi ai vari servizi e sui propri dati
personali.
Per FOAF fu quindi ideata una strategia di assegnazione dei nomi decentralizzata. Tale strategia si
basa sul presupposto che un indirizzo email è assegnato ad un'unica persona. Dunque un indirizzo
email potrebbe essere usato per identificarne il proprietario; tuttavia usare l'URI dell'indirizzo email
per riferirsi al proprietario è concettualmente sbagliato poiché si otterrebbe un URI che identifica
due risorse: l'indirizzo email e la persona. Inoltre una persona potrebbe avere più indirizzi email
ognuno utilizzato per un particolare scopo.
L'idea di usare un indirizzo email per identificare una persona rimane comunque valida. Invece di
usare l'URI dell'indirizzo email come identificatore per il proprietario si può semplicemente
assumere che tutte le descrizioni di una persona che includono l'affermazione “l'indirizzo email di
questa persona è [email protected]” si riferiscano allo stesso individuo.
FOAF funziona esattamente in questo modo. Al fine di combinare l'informazione relativa ad una
particolare persona si assume dunque che un indirizzo email sia una inverse-functional property,
ovvero che un indirizzo email abbia un solo proprietario.
10
RIFERIMENTI
[1]
T. BERNERS-LEE, R. FIELDING, L. MASINTER, “RFC 3986 - Uniform Resource
Identifier (URI): Generic Syntax”, Network Working Group, 2005
[2]
WIKIPEDIA, “Uniform Resource Identifier”,
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier, 2006
[3]
R. FIELDING, J. GETTYS, J. MOGUL, H. FRYSTYK, L. MASINTER, P. LEACH, T.
BERNERS-LEE, “RFC 2616 - Hypertext Transfer Protocol – HTTP/1.1”, Network
Working Group, 1999
[4]
T. BERNERS-LEE, “What do HTTP URIs Identify?”,
http://www.w3.org/DesignIssues/HTTP-URI, 2002
[5]
D. Booth, “Four Uses of a URL: Name, Concept, Web Location and Document Instance”,
http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm, 2003
[6]
TAG, “httpRange-14: What is the range of the HTTP dereference function?”,
http://www.w3.org/2001/tag/issues.html#httpRange-14, 2005
[7]
K. SHAFER, S. WEIBEL, E. JUL, J. FAUSEY, “Introduction to Persistent Uniform
Resource Locators”, http://purl.oclc.org/docs/inet96.html
[8]
K. SOLLINS, L. MASINTER, “RFC 1737 - Functional Requirements for Uniform
Resource Names”, Network Working Group, 1994
[9]
L. MASINTER, “"duri" and "tdb" URN namespaces based on dated URIs”,
http://larry.masinter.net/duri.html, 2004
[10]
T. KINDBERG, S. HAWKE, “RFC 4151 - The 'tag' URI Scheme”, Network Working
Group, 2005
[11]
E. DUMBILL, “Finding friends with XML and RDF”,
http://www-128.ibm.com/developerworks/xml/library/x-foaf.html, 2002
11