Type Indexes

Version 1.0.0, Editor’s Draft, 2022-08-31

More details about this document
This version
Latest version
Latest published version
Timea Turdean
Jeff Zucker
Virginia Balseiro
Sarven Capadisli
Tim Berners-Lee
MIT License
Document Status
Editor’s Draft
Unique Identifier
W3C Solid Community Group


Status of This Document

This section describes the status of this document at the time of its publication.

This document was published by the Solid Community Group as an Editor’s Draft. The sections that have been incorporated have been reviewed following the Solid process. However, the information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.

Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.




This section is non-normative.

This document uses terminology from the Solid Protocol [SOLID-PROTOCOL] and Web Access Control [WAC] specifications.

The Solid WebID Profile specification defines the following terms. These terms are referenced throughout this specification.

Solid Profile
A Solid Profile is...
Solid Profile
An extended profile is...


Prefixes and Namespaces
Prefix Namespace Description
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [rdf-schema]
rdfs http://www.w3.org/2000/01/rdf-schema [rdf-schema]
ldp http://www.w3.org/ns/ldp# [LDP]
solid http://www.w3.org/ns/solid/terms# Solid Terms
pim http://www.w3.org/ns/pim/space# Workspace Ontology
acl http://www.w3.org/ns/auth/acl# ACL Ontology
dcterms http://purl.org/dc/terms/ [DC-TERMS]


All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Type Indexes

A Type Index is a document containing statements that link specific types of data to specific locations. An app might ask a user where they want to store items of type Bookmark and then write that location in the Type Index. Thereafter another app can find the bookmarks by looking for the location in the Type Index. Apps that want to remember user's choices will read from and write to the Type Index. Since users will undoubtedly have data they want to keep private, there are two Type Indexes - one readable by any app (publicly discoverable) and one only readable by apps operating on behalf of the WebID owner (not publicly discoverable).

To find the Type Indexes, an app SHOULD load the WebID Profile Document and if the app has access, also the Preferences Document. In these loaded documents one can find triples where the WebID as subject and the following predicates: for the Public Type Index document the solid:publicTypeIndex predicate, and for the Private Type Index document the solid:privateTypeIndex predicate.


An example for a Public Type Index Resource that is located in settings and is called publicTypeIndex.ttl linked from the profile is:

<#WebID> <http://www.w3.org/ns/solid/terms#publicTypeIndex> </settings/publicTypeIndex.ttl> .

An example for a Private Type Index Resource located in settings and is called privateTypeIndex.ttl linked from the profile is:

<#WebID> <http://www.w3.org/ns/solid/terms#privateTypeIndex> </settings/privateTypeIndex.ttl> .

Here is a diagram showing an example set of Type Indexes:

Type Indexes Example

Public Type Index

The Public Type Index document contains registration entries that are discoverable by outside users and applications but which are not necessarily accessible to all applications or users. For example, suppose I have one address book that is only for myself, one that is for a specific group of colleagues, and one that is for the general public. The one that is only for me should be listed in the private type index. The other two should be listed in the public type index. The fully public listing will point to a publicly accessible resource while the one just for my colleagues will point to a resource restricted by access control methods. Both the public and restricted resources are discoverable in the public type index because an app that is not operating as the WebID owner can not see the private type index.

Example: Public Type Index that is a Linked Document.

@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix vcard: <http://www.w3.org/2006/vcard/ns#>.
@prefix bk: <http://www.w3.org/2002/01/bookmark#>.

  a solid:TypeIndex ;
  a solid:ListedDocument.

<#ab09fd> a solid:TypeRegistration;
  solid:forClass vcard:AddressBook;
  solid:instance </public/contacts/myPublicAddressBook.ttl>.

<#bq1r5e> a solid:TypeRegistration;
  solid:forClass bk:Bookmark;
  solid:instanceContainer </public/myBookmarks/>.
Type registration containing public resource of type vcard:AddressBook located at the resource address </public/contacts/myPublicAddressBook.ttl> and a resources of type bk:Bookmark located in the container address </public/myBookmarks/>

Private Type Index

The Private Type Index document contains registration entries that are private to the user and their apps. It is intended for types of resources meant only to be accessed by the WebID owner.

Example of a Private Type Index that is an Unlisted Document, This contains a private resource of type vcard:AddressBook located at the resource address </private/contacts/myPublicAddressBook.ttl> and a resources of type bk:Bookmark located in the container address </private/myBookmarks/>:

Type Index Registration Entries

The type index documents MAY contain any number of statements of type solid:TypeRegistration which map RDF classes/types to their locations in a WebID owner's dataspace/root storage.

The registration entries map a type to a location and MUST use one of two predicates:

solid:instance maps a type to an individual Solid resource, typically an index or a directory listing resource such as an Address Book.

solid:instanceContainer maps a type to a Solid container which the client would have to list to get the instances of that type.

Supplying missing type index documents

If one or both of the type indexes are missing, an app needing to write to them that doesn't have Write and Control access to the pod MAY warn the user that their indexes are missing and that they should use a Pod Management App to fix their profile.

If one or both of the type index documents are missing and the app does have Write and Control access to the pod, the app MAY create documents. The public type index document SHOULD be publicly readable, writable by the user (or a group delegated by the user), and a pointer to it MUST be placed in the WebID Profile Document. The private type index SHOULD be readable and writeable only by the WebID owner and a pointer to it MUST be placed in the Preferences Document.

(Note if the type index file is created but the pointer to it not stored, then this risks, on a future occasion, another separate empty resource being created, leading to confusion and possible loss of data.)


Note: This section is "at risk" in that is more recent and less tested than the rest of this spec.

A user may use not only their own type indexes to find and remember things, but also may use the type indexes of users which are organizations, such as projects, to which they are affiliated. To enable this, a triple {user} solid:community {org} . is placed in either the user's private preferences or public profile. The org node's URI is the WebID URI of the project, etc.


Normative References

Dublin Core Metadata Terms, version 1.1. DCMI Usage Board. DCMI. 11 October 2010. DCMI Recommendation. URL: http://dublincore.org/documents/2010/10/11/dcmi-terms/
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/
Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 28 March 2022. Version 0.1.0. URL: https://solidproject.org/TR/oidc
Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo. W3C Solid Community Group. 17 December 2021. Version 0.9.0. URL: https://solidproject.org/TR/protocol
Web Access Control. Sarven Capadisli. W3C Solid Community Group. 11 July 2021. Draft. URL: https://solidproject.org/TR/wac
Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
WebID 1.0. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor’s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/

Informative References

Making content usable for people with cognitive and learning disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
Privacy Principles. Robin Berjon; Jeffrey Yasskin. W3C. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/privacy-principles/
Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/