Application interoperability
Solid Application Interoperability
Added in: activitypods@2.0
Solid Application Interoperability is a complex specification which is not yet complete. We’ve implemented everything we could on ActivityPods 2.0 and we are currently working on implementing the remaining parts.
What we don’t implement yet
- We’re not using ShapeTrees for the time being: instead, applications just declare the classes they want to manage (see below).
- We only handle registration with
Applications
, not with otherSocialAgents
(we continue to use WAC permissions for the latter) - Pods don’t declare a
DataRegistry
. TypeIndex can be used instead. - Applications don’t declare
AccessNeedDescription
. On the other hand, in theAccessDescriptionSet
it is possible to declareClassDescriptions
. - Pods only create
AccessGrants
andDataGrants
, notAccessAuthorizations
andDataAuthorizations
. Grants can be shared with the registered application, while Authorizations cannot. - Pods don’t declare
RegistrySet
,ApplicationRegistry
,AuthorizationRegistry
. We just readApplicationRegistrations
,AccessGrants
andDataGrants
in their dedicated containers.
Class descriptions
Added in: activitypods@2.0
Applications can describe the types of resources (classes) they use. This enables user-friendly information to be displayed on the authorization screen, as well as on the data browser.
The following predicates are used:
skos:prefLabel
: A human-readable label of the resource typeapods:labelPredicate
: The predicate used to label the resourceapods:openEndpoint
: An URL that can be used to open the resourcesapods:icon
: An image to describe the resource type
Class descriptions are located in the interop:AccessDescriptionSet
Type Indexes
Added in: activitypods@2.0
TypeIndexes are Solid’s recommended method to discover in what LDP containers the resources are being stored. In ActivityPods, we have implemented a public TypeIndex, that is linked to the WebID with the solid:publicTypeIndex
predicate.
Since we don’t support yet RDF documents (planned for version 3.0), we use a custom solid:hasTypeRegistration
predicate to link the solid:TypeIndex
with the various solid:TypeRegistration
, and we dereference them for easier handling. See this issue for more details.
In addition to the solid:forClass
and solid:instanceContainer
predicates used by TypeRegistrations to indicate, respectively, the types and their container’s URI, we are also persisting predicates that are used by the Pod provider’s data browser. They are the same as the ClassDescription.
skos:prefLabel
: A human-readable label of the resource typeapods:labelPredicate
: The predicate used to label the resourceapods:openEndpoint
: An URL that can be used to open the resourcesapods:icon
: An image to describe the resource type
Additionaly, two predicates are used in relation with apps registration:
apods:defaultApp
: The default app with which to open the resource typeapods:availableApps
: All the apps that are able to handle this resource type