2012-02-07 11 views
5

Il documento "Resource Description Framework (RDF): Concetti e sintassi astratta" documento Section 6.4 afferma che "Un riferimento URI all'interno di un grafico RDF (un riferimento URI RDF) ... produrrebbe una sequenza di caratteri URI valida (per RFC2396, sezioni 2.1) rappresenta un URI assoluto con identificatore di frammento opzionale ... "È una "stringa di query" consentita in un URI utilizzato in RDF?

RFC 2396, sezione 2.1 parla solo della codifica dei singoli caratteri. Non parla di quali sezioni di un URI standard sono consentite all'interno di RDF.

In alcuni documenti RDF che ho visto, il termine "URI assoluto" sembra fare riferimento solo al domain.tld/percorso/nome # opzionaleFragment di un URI ma senza menzione se una stringa di query (? Key1 = valore1 & key2 = value2) (talvolta noto come dati CGI) è consentito o non consentito. L'altra documentazione RDF usa solo il termine "URI assoluto" in contrasto con un URI relativo (/ solo/a/percorso).

La ricerca di "stringa di query URI RDF" è piena di falsi risultati su cose come SPARQL.

Quindi, la mia domanda è: è una stringa di query HTML standard consentita in un URI utilizzato in RDF o RDFa?

In caso contrario, perché no? Comprendo che un URI non è un URL e non sarà necessariamente utilizzato per recuperare una pagina Web da un server. Tuttavia, i processori RDF leggono quegli URI e penso che potrebbero avere qualche aiuto sotto forma di ulteriori metadati che potrebbero essere trasmessi attraverso queste stringhe di "query".

[Aggiornamento 2/9/2012] Ecco il punto della mia domanda: sto cercando un modo per indicare la "forza" di una connessione. Per esempio, non tutti sono focosi: conoscono tutti ugualmente bene. Potremmo esserci appena incontrati per alcuni minuti in una conferenza. O potrei aver vissuto con qualcuno per anni. Fa lo stesso con FAOF. Tuttavia, se fossi in grado di scrivere foaf: know? Strength = + 50 allora i processori che non sanno cosa fare con la chiave di forza potrebbero ignorarlo mentre quelli che sono "solid aware" avrebbero dei preziosi metadati aggiuntivi. Potrei creare un vocabolario che include il termine "concorda con", quindi lasciare che il valore della chiave forza = da 0 a 100 (indicando le percentuali di accordo). Quindi coprirei l'intera gamma di accordi con un termine di vocabolario. {Nota: avevo pensato di consentire all'intervallo di andare da -100 a +100 per coprire un intervallo di disaccordo. Tuttavia, per compatibilità con le versioni precedenti, avremmo bisogno di un termine "disaccordoCon" in modo che i processori che non sono "consapevoli della forza" conoscessero ancora la differenza tra "agreeWith" e disaccordo con. "}

Così com'è ora, sembra che lì non è un modo per un ragionatore RDF di conoscere la differenza tra "incontrato a malapena" e "lo conosce meglio di quanto lui stesso sa". La decisione di trattare ogni singolo URI di predicato con un valore diverso in una coppia chiave-valore come un valore il predicato separato e completamente indipendente sembra gettare quasi tutte le informazioni più preziose su una connessione, tutto per semplificare la scrittura del codice e l'elaborazione veloce.

Ci potrebbero essere altri usi preziosi per coppie chiave-valore in un stringa di query diversa dalla creazione di a n soggetto, predicato o oggetto completamente separati: potrebbero essere usati per indicare chi ha aggiunto una particolare entità a un file .RDF redatto congiuntamente. Così com'è, tutto ciò che un ragionatore RDF sa è che esiste una tripla, là fuori, da qualche parte? Non ha ulteriori informazioni su cui basare il proprio ragionamento. Le passphrase crittografate potrebbero essere utilizzate per convalidare l'affidabilità di una fonte piuttosto che semplicemente decidere di fidarsi o non fidarsi di un intero dominio.

risposta

7

Sì.

(Cosa, vuoi di più?)

RDF si riferisce a cose che utilizzano quelli che vengono chiamati colloquialmente "URL". Se vuoi essere più preciso, IRI (essenzialmente un modo per includere più di ASCII negli URL, ecco perché puoi usare caratteri esotici nella barra del browser). La risposta più accurata è troppo noiosa per relazionarsi, quindi assumere IRI.

RDF utilizza riferimenti assoluti. Le sue sintassi possono utilizzare riferimenti relativi (ad esempio foo/bar) ma vengono risolti rispetto alla base del documento per diventare assoluti. Esattamente come i link html, infatti.

Oltre la sintassi, RDF non riguarda gli interni di questi riferimenti. Li confronti semplicemente carattere per carattere. Di conseguenza:

  • http://example.com/foo/bar == http://example.com/foo/bar
  • http://example.com/foo/bar?query=x == http://example.com/foo/bar?query=x
  • http://example.com/foo/bar != http://example.com/foo/bar?query=x
  • http://example.com/foo/bar#x == http://example.com/foo/bar#x
  • http://example.com/foo/bar != http://example.com/foo/bar#x
  • http://example.com/%66oo/bar != http://example.com/foo/bar

Nota che non si persino ottenere la normalizzazione.

E in particolare RDF non vede la parte della query come qualcosa di speciale.

+0

Quindi, se dovessi scrivere un processore RDF che ha trattato qualsiasi URI con identico domainName.tld/percorso/nome/porzioni come entità identiche e quindi trattato qualsiasi stringa di query come metadati semplicemente aggiuntivi sulla particolare connessione, allora quel processore RDF sarebbe fuori dalle specifiche? Pensi che ci sarebbe alcun interesse per un processore RDF che ha funzionato in questo modo? Non vedo la logica nel trattare example.com/foo/bar come completamente estraneo a example.com/foo/bar#x oltre a rendere i processori di programmazione più semplici. RDF potrebbe essere molto più ricco di quello che questo sistema rende possibile. – GrantRobertson

+0

Se si applica un certo grado di normalizzazione è discutibile. Tuttavia ignorare la stringa di query è decisamente sbagliato. Suggerirebbe che 'http: //example.com/? Personid = xxx' fosse identico per tutti' xxx'. Ma potresti rendere esplicita la relazione: inserisci una relazione (cioè tripla) che collega a 'http: // example.com /'; oppure potresti creare una funzione di equivalenza SPARQL personalizzata 'ex: sameIgnoringQuery (x, y)'. – user205512

+0

OK, penso di poter rivelare il mio piano segreto. : ^) Vedere il mio post originale per ulteriori informazioni. – GrantRobertson

4

Per confermare la risposta sopra, sì.

Gli URI sono puramente sintattici quindi si applicano le regole sopra elencate.

Gli URI che utilizzano un frammento non sono dereferenziabili e quando un agente tenta di dereferenziare uno, lo risolve a un altro URI (che è un URL) rimuovendo il frammento.

Infine, si consiglia di utilizzare dell'IRI (Internationalized Resource Identifiers) al posto di URI, ove possibile

http://www.ietf.org/rfc/rfc3987.txt

Questo specificies diversi vincoli syntatic e restrizioni.

+0

Grazie mille. Se non fosse per questo forum, non avrei mai sentito parlare di IRI. So cosa leggerò domani. – GrantRobertson

Problemi correlati