Assegnazione di URI a risorse RDF

Question

Sto scrivendo un'app desktop utilizzando le tecnologie Gnome e ho raggiunto lo stadio che ho iniziato a pianificare il supporto di Semantic Desktop.

Dopo un sacco di brainstorming, schizzo di idee e modelli, scrittura di note e lettura di RDF e argomenti correlati, alla fine ho trovato una bozza di progetto .

La prima cosa che ho deciso di fare è definire il modo in cui fornisco gli URI alle risorse , ed è qui che mi piacerebbe sentire il vostro consiglio.

Il mio programma si compone di due parti:

1) Al livello inferiore, uno schema RDF è definito. È un set standard di classi e proprietà , possibili estese dagli utenti che desiderano più opzioni (utilizzando un linguaggio di definizione tradotto in RDF).

2) Al livello alto, l'utente definisce le risorse utilizzando tali classi e le proprietà .

Non c'è nessun problema con il livello più basso, perché il modello di dati è pubblico: Anche se un utente decide di aggiungere nuovi contenuti, lei è molto gradito a condivisione e rendere le applicazioni di altre persone hanno più funzioni. Il problema è con la seconda parte. Nel livello superiore, l'utente definisce le attività, riunioni, appuntamenti, piani e orari. Questi possono essere privati ​​e l'utente potrebbe preferire di avere qualsiasi informazione nell'URI rivelando la fonte delle informazioni.

Così qui sono le domande che ho per la testa:

1) Quale schema URI dovrei usare? Non ho un sito web o alcuna pagina web , quindi l'uso di http non ha senso. Inoltre, non sembra che l'intuizione di possa utilizzare qualsiasi altro URI standard registrato dalla IANA. Ho considerando due opzioni: Utilizzare alcuni personalizzato, il mio, URI nome schema per risorse pubbliche, e utilizzare un URN nuda per quelli privati, qualcosa di simile a questo :

urn : random_name_i_made_up : some_private_resource_uuid 

Ma mi chiedevo se uno schema URI personalizzato è una buona decisione, io sono aperto per ascoltare le tue idee :)

2) Come nascondere le risorse private? Da un lato, può essere molto utile per l'URI per indicare da dove proviene un'attività, specialmente quando le attività sono condivise e delegate tra le persone. D'altra parte, non è prendere in considerazione la privacy. Poi stavo pensando, posso/dovrei usare due diversi stili URI a seconda delle impostazioni dell'utente? Ciò creerebbe alcune incoerenze . Non sono sicuro di cosa fare qui, dal momento che non ho esperienza con URI. Spero che tu abbia qualche consiglio per me.

Answer 1

1) Quale schema URI dovrei usare?

Vorrei consigliare lo standard urn:uuid: seguito dall'UUID della risorsa. Utilizzare gli standard è generalmente da preferire rispetto alle soluzioni di produzione nazionale!

2) Come nascondere le risorse private?

Non utilizzare schemi identificativi diversi. Cercando di eseguire l'autorizzazione e il controllo dell'accesso nello schema dell'identità, si mescolano gli strati in un modo che è destinato a causare dolore in futuro. Ad esempio, cosa succede se un utente rende pubblici alcuni contenuti privati ​​(ad esempio una bozza) (è ora nella sua forma pubblicabile)?

Avere un'unica soluzione identificativa uniforme, quindi fornire uno o più servizi che possono o non possono risolvere un determinato identificatore in un documento, a seconda del contesto (identità dell'utente, metadati sul contenuto stesso, ecc. Ecc.). Sì, è molto simile a un server HTTP, quindi potresti voler riconsiderare se avere un servizio HTTP incorporato nella tua architettura. In caso contrario, il servizio di cui hai bisogno avrà molte somiglianze con HTTP, devi solo chiarire le circostanze in cui un identificatore può essere risolto in un documento, cosa succede quando ciò non è possibile o non consentito, ecc.

Si potrebbe anche voler considerare dove si aggiungerà il maggior valore. Ri-inventare i protocolli di accesso ai servizi di base può essere un esercizio divertente, ma i tuoi utenti possono ottenere più valore se riutilizzi i componenti standard a livello di servizio di base e si concentrano invece sull'innovazione e sull'aggiunta di funzionalità una volta che l'utente ha effettivamente accesso al oggetti di contenuto.