Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Process for discovery of suitable apps for a resource

Aperta
  • Qualcosa non va?
#324 9 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
documentation

Direzione di ricerca

Inizia con la specifica dell’albero di shapes, la registrazione dei dati, il profilo di identità dell’applicazione e le questioni relative agli header Link descritti nell’issue. Traccia il modo in cui un’istanza di dati viene associata alla propria registrazione e in cui un’app scopre gli shapes supportati. Il lavoro è completato quando il flusso di discovery proposto è stato definito e sono stati documentati i link richiesti e il loro livello di obbligatorietà.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

I would like to confirm my understanding of use cases where a user receives a uri and wishes to check whether an app can open it, or identify an app to open it with.

My understanding is that the intention would be that the shape tree of the resource is identified, and then compared with the registered shape trees provided by application identity profile documents.

Following the spec, it appears there is no link from a data instance to its data registration. Is this correct?

Instead, this use case seems to be covered by the shape tree spec, with the link header providing the shape tree manager.
If so, is there a link between the data registration and shape tree manager that needs to be specified?
And would this link header be a should or a must? Will servers consistently provide it? (it's a must for shape trees)

As a point of comparison, I like the way I can:

  1. dereference a resource
  2. look up its rdf:type
  3. check whether apps support that type

I understand the need to check shapes rather than just types, but my preferred option would be to replace step (2) with looking up the shape or shape tree expressed in a single triple rather than by checking headers or loading registries. I expect that might be too simplistic, but I don't yet understand why.

Lingua principale
Bikeshed
Stelle
58
Fork
18
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solid/data-interoperability-panel

Tutte le issue di solid/data-interoperability-panel

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.