solid/vocab

Solid Vocabularies

Solid Vocabularies

This is a directory of ontologies and vocabularies used by the Solid project.

Table of Contents

• Created for Solid
• Used in Core Solid Spec
• Recommended by Solid

Created for Solid

These vocabularies are created for the Solid project, and are contained in this repo.

solid/app

Contains a snapshot of the previous App Configuration vocabulary for Solid apps. Warning: do not use, the app configuration spec is currently in flux.

Source code: solid-app.ttl

solid/terms

Contains core Solid terms, such as links from a Solid WebID Profile to user account resources, WAC related predicates, and so on.

Canonical prefix URL: http://www.w3.org/ns/solid/terms#

Source code: solid-terms.ttl

solid/oidc

Contains OpenID Connect terms as used in the Solid-OIDC specification.

Canonical prefix URL: http://www.w3.org/ns/solid/oidc#

Source code: solid-oidc.ttl

solid/oidc-context

Contains a JSON-LD context document as used in the Solid-OIDC specification.

Canonical URL: https://www.w3.org/ns/solid/oidc-context.jsonld

Source code: solid-oidc-context.jsonld

Used in Core Solid Spec

These vocabularies are used in required/normative sections of the Solid Spec.

auth/acl

Used for Authorization/Web Access Control of Solid resources.

Canonical prefix URL: http://www.w3.org/ns/auth/acl#

auth/cert

Used in the Public Key Certificates portion of the Solid WebID Profile document.

Canonical prefix URL: http://www.w3.org/ns/auth/cert#

dc/terms

Solid uses the Dublin Core Terms vocabulary in several apps, but specifically in the Certificates section of the WebID Profile document.

Canonical prefix URL: http://purl.org/dc/terms/

foaf

The FOAF ontology is used in WebID Profile documents and Web Access Control .acl resources.

Canonical prefix URL: http://xmlns.com/foaf/0.1/

ldp

Describes Linked Data Platform terms. Used in the Content Representation and REST API sections of the Solid spec.

Canonical prefix URL: http://www.w3.org/ns/ldp#

owl

The Solid spec uses the Web Ontology Language vocab for specifying Extended Profiles, via owl:sameAs links from the WebID Profile document.

Canonical prefix URL: http://www.w3.org/2002/07/owl#

pim/space

Used in the Solid WebID Profile spec for discovery of user account resources (to link to Root Storage and Preferences resources).

Canonical prefix URL: http://www.w3.org/ns/pim/space#

posix/stat

Describes terms for POSIX-like files and directory listings. Used in the Solid REST API when listing Containers.

Canonical prefix URL: http://www.w3.org/ns/posix/stat#

Source code: posix-stat.rdf

rdf-schema

The Solid spec uses the RDF Schema vocab for specifying Extended Profiles, via rdfs:seeAlso links from the WebID Profile document.

Canonical prefix URL: http://www.w3.org/2000/01/rdf-schema#

Recommended by Solid

These vocabularies and ontologies are recommended by the Solid project for maximum interoperability between apps.

vcard

The vCard Ontology is recommended for Contact Management like applications for use with the Solid ecosystem.

Canonical prefix URL: http://www.w3.org/2006/vcard/ns#

Solid Extensions:

• AddressBook - an RDF class for representing address books that contain contacts.

vocab's Issues

Property to indicate an agent's preferred proxy endpoint for applications to use

This issue was originally raised at https://gitter.im/solid/node-solid-server?at=59f0b46501110b7231fd132e with some interest in its use:

In order for applications to respect a user's privacy (to some extent [*]) an agent's profile description can signal their preferred proxy endpoint. Applications upon discovering this property (eg solid:proxyUrl or solid:preferredProxy ?) can use it where applicable. When this piece of information in not available, applications would typically use their built-in proxy endpoint as default. Hence, once the agent's preferred proxy endpoint is known, cool applications can override the default (eg linkeddata/dokieli#230 )

solid:preferredProxy
  a rdf:Property ;
  rdfs:label "preferred proxy" ;
  rdfs:comment """An agent's preferred proxy endpoint for consuming applications to use. The value of the property is intended to be used as the base URL for the request eg. the preferred proxy as literal: `https://example.org/proxy?uri=` would be used to request `https://example.net/profile/card#me` as `https://example.org/proxy?uri=https://example.net/profile/card%23me`"""@en ;
  rdfs:domain foaf:Agent ;
  rdfs:range rdfs:Literal
  .

domain and range could be omitted in the vocabulary definition document. Range is a literal because we want the application to use that as the base URL for the intended request.

Example profile statement:

<http://csarven.ca/#i>
  solid:preferredProxy "https://example.org/proxy?uri=" .

I could not find an existing vocabulary that would indicate this, so I'm raising it here.

[*] Obviously applications do not have to care about this nor should agents rely on the application to use their preferred proxy endpoint. The bottom line is of course the level of trust an agent puts on the application that they use - which could very well mean that the application will use their built-in proxy endpoint for certain operations.

Quotas

For the issue in nodeSolidServer/node-solid-server#841 , which is urgent, we are discussing to add some RDF so that apps can use the data.

I would prefer to use a datatype, so something like this:

<#me> solid:nvmQuota "25"^^ex:megabyte .

but I have also considered the option of e.g.

<#me> solid:nvmQuota [
  a solid:MaxQuota ;
  posix:size "25000000" .
].

Look at making the app namespace be a subclass of DOAP

There are currently terms in the solid-app vocab can do not need to be defined there and can be reused from existing vocabs.

attributing app which generated the content - as:generator

I would like to include in content, which I publish on The Web, attribute apps which I used for generating given content. So far as:generator seems to me like an appropriate property.

@melvincarvalho I would also use that later myself for statistics on how much i use which app and using it as factor in prioritizing how I express my gratitude to contributors of given app 🎁

Internationalization: vocabs

Support additional languages in pim/space, solid/terms...

Application and Thing Registries may be needed

It seems when building something like a POD manager, quick access and searchability of all Things in the POD and all Apps registered to the POD is a necessary ingredient. Right now, there's no dedicated registries for these items. TypeIndex might be usable, but it seems like it would be good to split these out into separate registries.

They would need to also include private and public indexes as well.

Understanding and creating Solid vocabs

Decide on whether to have a "core" vocabulary and the rest e.g., apps, server, ..?

Decide on whether to use a single or multiple namespace (depends on previous point).

acl.n3 has a number of minor English errors

All human-facing text in acl.n3 needs a review by an English speaker with native-level fluency. There are a number of minor idiomatic and/or grammatical errors (things like including a "to" in a verb conjugation where it doesn't belong) in the current texts. (I noticed them in adjacent text when skimming a recent PR after it was merged, which I hadn't read over before the merge or I'd have suggested the fixes there.)

Define Solid vocabulary

consider ianarel:webmention instead of solid:inbox

It seems that webmention link relaion will have canonical URI hosted by IANA

• w3c/webmention#30
• mnot/I-D#140

Maybe solid can use it instead of defining new term inbox ?

Add type registry related classes and properties

The type registry spec mentions the following new terms.
Add them to the solid-terms vocabulary:

• publicTypeIndex
• privateTypeIndex
• TypeIndex
• ListedDocument
• UnlistedDocument
• TypeRegistration
• instance
• instanceContainer
• forClass

Add `solid:InsertDeletePatch`

The solid protocol refers to this type but it is not defined in the vocab. See https://solidproject.org/ED/protocol#server-patch-n3-type

IDE Namespace Fetcher

I started to make a list of ontologies in my tools spreadsheet then came across prefix.cc and wondered about a vocab fetcher, that might go find a suitable term, then help add it via an IDE like sublime or atom, et.al.

One of the issues that seem to exist is a difficulty for people to find existing ontology terms, etc.

The idea here - is to help solve that problem.

Property to indicate the version of applications that have been used

I'm going to update a Solid application and I want it to upgrade the data on PODs that interacted with older versions of my app. In order to know if this is necessary, and in case it is what needs to be modified, I need to know which was the last version that interacted with the POD. An analogous concept with databases would be migrations. Because the POD may still be accessed with old versions of the app, or even other apps who understand the previous schema, all changes will be backwards compatible.

In order to achieve this, and maybe other features, it is necessary to store which version of the app interacted with the POD. I guess in a more complex scenario this could be granular per-container or something, but for now that's a use-case I'm not contemplating.

What I will be doing for now is use the http://vocab.org/open/ ontology and write the following information to /settings/prefs.ttl (read from pim:preferencesFile):

<https://userdomain.com/profile/card#me> <http://open.vocab.org/terms/uses> <https://github.com/user/app/releases/tag/v0.1.1> .

With this, I'll be able to know the latest version of the app and upgrade the data accordingly. But I think we could have something more specific to Solid, because I'm not sure using the settings file is the best idea.

Discovering the application workspace

(Putting ws:masterWorkspace aside) ws:workspace only leads to Workspaces, which would then require a second round of requests for all of the workspaces to discover the application workspace.

I think we need a specific property to help discover the application workspace (i.e., which is an instance of a solid-app:PreferencesWorkspace faster. It is sufficiently high profile that it deserves its own dedicated property.

ws:applicationWorkspace a rdf:Property ;
     :label "application workspace";
     :range ws:Workspace;
     #or :range solid-app:PreferencesWorkspace;

Example usage:

<http://example.org/> ws:applicationWorkspace <../Applications/> .

<../Applications/>
    a <http://www.w3.org/ns/solid/app#PreferencesWorkspace> ,
       <http://www.w3.org/ns/pim/space#PreferencesWorkspace> ,
       <http://www.w3.org/ns/pim/space#Workspace> ;
    <http://purl.org/dc/terms/title> "Applications preferences workspace" .

Vocabulary Stability: How much is needed and how do we achieve it?

This is splitting off a thread from another issue: solid/solid#35 (comment)

edit to clarify: we're interested in this issue as it applies to solid, not in general.

The meaning of an RDF graph depends on the meaning of the predicate URIs (aka property ids) used in that graph. If I say {<sandro> <http://example.org/likes> <salmon>}, and we assume for now the terms <sandro> and <salmon> have their conventional meanings, that statement might mean I like salmon, or I hate salmon, or I am a salmon, or I own some salmon, or ... practically anything. It totally depends on what the predicate <http://example.org/likes> is accepted to mean. That triple might mean I promise to pay $1000 to each person who walks up to me and says "spaghetti". If we all agreed that's what it meant, that would be okay. (Similar issues arise around the terms <sandro> and <salmon> but they're no harder to solve, so let's worry about them later.)

The problem is, how do we all come to agreement about what a predicate URI means? And what happens if that meaning changes over time?

If I was mistaken about the meaning of that term when I made that statement, I've ended up accidentally providing false information. If the meaning changes after I make the statement, and it's not clear the meaning has changed, I've been turned into a liar.

In general, at this point, the RDF community shrugs and doesn't worry too much about this. I suggest this is one of the reasons people who need their computers to do the right thing shrug and walk away from RDF. This github issue is a place for folks to talk about this a little, if they want.

There is vast history around this. I think it was most actively discussed in 2002-2003 as the RDF Core WG tried to decide what the new RDF specifications should say, under the heading "Social Meaning" (as opposed to "formal meaning", as in the formal model theory for RDF). Eventually they decided consensus was impossible and chose to remain silent.

Two bits of historical reading:

• My long, passionate, and unsuccessful argument for 'the gold standard' (TimBL's phrase), the idea that the person who controls the web content available at a URI gets to define what it means. https://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0043.html
• Agenda with notes for a meeting about Social Meaning of RDF: https://www.w3.org/2001/sw/meetings/tech-200303/social-meaning

I'm sure there's lots more.

I don't know of any credible solution yet. It's become clear to me that dereference is of little use, because it doesn't guarantee stability. And a standards process is also of little use because it's just too slow and expensive. The best we can do today is a very slow and expensive combination of things: make a standard, have an active community that agrees about the meaning, and also make dereference work. And even that's not good enough for many applications areas, I suspect.

I think the solution is going to be something where the text of the spec is provably frozen, and there's good mapping between versions, so meanings can nicely evolve, free from any confusion about which meaning was intended when a given document was written, but also usable when the meaning hasn't changed too much for a particular application. Two of my sketches in this direction are http://decentralyze.com/2014/06/30/growjson/ and http://www.w3.org/ns/mics .

Property for proxy URL prefix

Might be a good idea to have the resources declare their preferred proxy URL. This is so that, proxy URLs can be discovered without hardcoding or maintaining the URLs in the application. That is, the application only needs to find the value of the property, and then use the prefix URL.

Example part of the response:

<http://example.org/> :proxyURLPrefix "http://example.org/,proxy?uri="

and/or:

Example part of the HTTP Header:

ProxyURLPrefix: http://example.org/,proxy?uri=

It is okay to try and use ,proxy?uri= in applications, but I think that expectation is not necessarily always going to work out in the wild. Servers are going to use whatever pattern they can and want. And, it is likely that they'll re-use an existing one instead of changing its path to a new one so that it is compatible with Solid - which is costly.

Missing solid:oidcRegistration property

As per the Solid authentication panel's current proposal, a client's WebID MUST include a single solid:oidcRegistration property.

See: https://solid.github.io/authentication-panel/solid-oidc/#clientids-webid

We possibly could describe it as follow:

solid:oidcRegistration
    a rdf:Property ;
    rdfs:comment "A JSON serialization of an OIDC client registration, per the definition of client registration metadata from [RFC7591] section 2."@en ;
    rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms> ;
    rdfs:label "oidc registration"@en .

@acoburn @csarven does this addition and the proposed comment make sense?

Move vocabs to gh-pages, version them

1. Version the relevant included vocabularies
2. Move the main branch to gh-pages, so they can be easily accessible from github.io

Process for replacing vocabulary terms that might be in use

create namespace for monkey patching existing vocabs

It seems that currently solid team promotes practice of dropping additional terms to namespaces under control of someone else. I think that creating dedicated namespace for such terms would provide a cleaner way of doing it.

http://www.w3.org/2006/vcard/ns does not include AddressBook or hasIndividual (as used in solid-contacts)

Such terms should have IRIs and definitions in namespace controlled by solid team, if they get adopted by vocab which they patch, combination of owl:equivalentProperty, owl:equivalentClass and schema:supersededBy can help with deprecating term from solid monkey patches.

Rename solid:inbox to ldp:inbox in apps

Replace solid:inbox by ldp:inbox

Add acl:TrustedApp

This is used as a way in the Solid Authentication for a user to say that a given web app (origin) is trusted and should not be blocked by cross-site security.

Use of CCO/BFO

A group of participants in the data interoperability panel have proposed the use of Common Core Ontologies by the Solid Ecosystem.

They have shared an example use case in the form of a User Profile, and described its use of CCO as follows:

As an extension of CCO, the User Profile also inherits and re-uses Basic Formal Ontology (BFO) and OBO Relation Ontology. Use of the methodology and standards derived from CCO, BFO, and RO, provides an integration layer for an individual’s profile data that maintains a transparent and unified semantics across domains and applications.

Also related to the above were issues and pulls in the Data Interoperability Panel - solid/data-interoperability-panel#24, solid/data-interoperability-panel#14.

On October 21st, 2019 - Jacob McConomy, Jim Schoening, and Mark Jensen gave a detailed presentation on CCO / BFO. Minutes from that presentation where recorded, and Slides were made available.

Creating this issue for others in the community to consider the use of CCO/BFO/OBO within the Solid Ecosystem.

cc: @mark-jensen, @JKReynolds

Update Spec Terms vocab and publish Solid Notifications Protocol vocab and JSON-LD context

Needs to be updated:

• https://github.com/solid/vocab/blob/main/spec.ttl at http://www.w3.org/ns/spec

Needs to be published:

• https://github.com/solid/vocab/blob/main/solid-notifications-context.jsonld at https://www.w3.org/ns/solid/notifications-context/v1
• https://github.com/solid/vocab/blob/main/solid-notifications.ttl at http://www.w3.org/ns/solid/notifications

---

@pchampin , will also assign the issue to you once you accept the invitation to be a collaborator in this repo.

Provide vocab/terms for Solid Pod related entities and functionalities

Hi. Currently the vocabulary does not provide sufficient concepts to represent information related to Pod functionalities. For example, Who developed/provided the App? Who is the Infrastructure provider for Solid? These terms should be provided through the solid vocabs to enable representing use-cases with correct granularity. This vocabulary should also establish the terms for entities that may take different roles in relation to Pods - e.g. who provided the server, who provided the software, etc. Such clarity in terms regarding entities, roles, and functionalities will help transparency in the Pod provisioning and use, maintaining records, and most importantly - legal tasks related to ensuring appropriate responsibilities and agreements are established.

For example, the following are based on existing standard for cloud terminology ISO/IEC 22123-1:2021 Information technology — Cloud computing — Part 1: Vocabulary where Solid is interpreted as a Data Storage technology (Solid and Pod are prefixed for informative purposes):

• Solid Pod is a cloud service of type data storage as a service (DSaaS) - which itself can be IaaS, PaaS, or SaaS.
• Pod Provider is a cloud service provider that makes services available
  • Pod Infrastructure Provider - provides the infra e.g. server
  • Pod Platform Provider - provides the platform on which Solid must be installed
  • Pod Software Provider - provides the software for Solid e.g. ESS
• Pod Customer is a cloud service customer that is in the business relationship of being provided the Solid Pod (can be a person or an organisation)
• Pod User is a cloud service user that uses Solid Pod (can be a person or a device or an application) associated with a Solid Pod Customer
  • Distinguish between Pod User as a Person and Pod App, this is for the Person, and we create separate concept for App
• Pod Partner is a cloud service partner that provides support or auxiliary activities for Solid Pods
• Pod Auditor is a cloud auditor that can audit Pods
• Pod Broker is a cloud service broker that negotiates between providers and customers
• Pod Developer is a cloud service developer
• Pod Capability Type is cloud capability type
  • Application/Software - Pod can provision and use the Provider's Applications
  • Infrastructure - Pod can provision and use the Provider's Infrastructure (e.g. processing, storage, networking)
  • Platform - Pod can deploy, manage, and run Customer's apps with Provider supported environments
  • Compute - Pod can use Provider to provision and use processing resources
  • Communication - Pod can use Provider for communication
  • Data Storage - Pod can use Providers provision and use of data storage
  • Network - Pod can use Providers networking capabilities
• Pod Agreement - agreement between Provider and Customer regarding the Pod
• Solid App - an application implementing the Solid Specs
• App Provider is the provider of a Solid App
• App User - user of the app
• App Developer - developer of the app
• App Agreement - agreement between App and User
• Interoperability Types
  • service - Pod Apps/Services can communicate with each other
  • transport - Pod Apps use common communication infrastructure
  • synctactic - Apps use interoperable format exchanges
  • semantic - Apps use interoperable data model
  • behavioral - Apps achieve expected outcome from interoperability
  • policy - portability is achieved while complying with policies
• Portability Types
  • data - can be taken out of the pod
  • pod data - can be moved from pod to pod
  • data synctactic - is provided with data formats
  • data semantic - is provided with data model
  • data policy - portability while complying with policies
  • application - can be moved pod to pod
  • application synctactic - application data is provided with formats
  • application instruction - application instructions are moved
  • application metadata - application metadata is moved
  • application behavior - application behavior is ported/same
  • application policy - application is moved while complying with policies

Revert incorrect deprecation

Had been on my todo list or quite a while.

1cd827c

The following should be reverted, because

• the committer committed the change without creating a pull request
• the idea was to deprecate, and delete was done instead
• the term was still in use

after this has gone back in, we can have a proper conversation about process, and what we'd like to see here.

cc @kjetilk @csarven

intended usage of ws:Storage and ws:Workspace

Where can I find documentation on intended use of ws:Storage and ws:Workspace? As I understand now:

• an instance of ws:Storage contains instances of ws:Workspace
  • ws:storage links Workspace to Storage
  • ws:workspace links Storage to Workspace
• data always gets stored in some instance of Workspace, never directly in an instance of Storage

Personal/Controlled/Public Storage & Private/Shared/Public Workspace

• which combinations of Storage and Workspace sub classes people working on implementations should allow?

move vocab namespace to HTTPS

currently: http://www.w3.org/ns/solid/terms#

should become: https://www.w3.org/ns/solid/terms#

Typo in ACL ontology?

I think I found a typo in the ACL ontology, as retrieved from http://www.w3.org/ns/auth/acl.

On line 16: acl:label "access"@en .
On line 26 and later: :label "append"@en;

The ACL namespace doesn't define 'label', but the rdf-schema, with prefix :, does.

I'm not sure if this is the right place to enter this issue, but I hope someone here knows what is :)

Update README

Discovering a storage's workspace

Currently we don't know a storage's workspaces. What we know (or do e.g., databox.me and some of the practices in our own profiles / preferencesFile) is that a user has workspaces, which can be seen as a single grouping of workspaces, and the storage in which they may be in is inferred through agent's ws:storage property.

I think this can be improved by using the property ws:workspace on instances of ws:Storage (or its subclasses), instead of using it on foaf:Agent. It will make it possible to declare different workspaces to different storages, especially when users may have multiple storages.

document use of FOAF and VCARD together

from gitter chat

elf Pavlik @elf-pavlik Nov 20 15:22
Since solid uses WebID Profiles does anyone see problem with simply registering in type index container for foaf:Person
profile.registerType(solid.vocab.foaf('Person'), 'https://storage.example/civr5dp8p0000n5prdue8qwip/civr5ft5z0000nppr6mrb0i1q/', 'container', true)

elf Pavlik @elf-pavlik Nov 20 15:23
so in this container would keep a copy of WebID profiles of all the people i want to bookmark
so each resource in that container would have <> foaf:primaryTopic {webid} just as WebID Profile it keeps copy of

elf Pavlik @elf-pavlik Nov 20 15:30
profile.registerType(solid.vocab.foaf('PersonalProfileDocument'), ...)
but that dosn't work if i want register containers to collect copies of profiles for groups, projects, organizations, places, events, books, movies ... anything

elf Pavlik @elf-pavlik Nov 20 15:45
registering types of things that documents describe seems more practical then trying to register types of documents

elf Pavlik @elf-pavlik Nov 20 15:50
vcard:VCard doesn't seem to distinguish the thing from the document as foaf:Person and foaf:PersonalProfileDocument do
The vCard class is equivalent to the new Kind class, which is the parent for the four explicit types of vCards (Individual, Organization, Location, Group)
above suggests that vcard:Individual matches foaf:PersonalProfileDocument and not foaf:Person

elf Pavlik @elf-pavlik Nov 20 15:57
and if social graph should rely on vcard then WebID and Solid WebID Profiles Spec should also use vcard not foaf

elf Pavlik @elf-pavlik Nov 20 16:16
http://vowl.visualdataweb.org/webvowl/index.html#iri=http://www.w3.org/2006/vcard/ns

:VCard a owl:Class ;
owl:equivalentClass :Kind .
:Individual a owl:Class ;
rdfs:subClassOf :Kind ;

I wonder what @deiu tied to do with https://github.com/linkeddata/contacts/blob/ac9f0888fea289b5645033f1533677d78a7fe932/app/app.js#L333

g.add($rdf.sym(''), RDF('type'), VCARD('VCard'));
g.add($rdf.sym(''), VCARD('hasIndividual'), $rdf.sym('#card')); // hasIndividual doesn't exist!
g.add($rdf.sym('#card'), RDF('type'), VCARD('Individual'));

elf Pavlik @elf-pavlik Nov 20 16:25
https://www.w3.org/TR/2004/REC-owl-guide-20040210/#equivalentClass1

The property owl:equivalentClass is used to indicate that two classes have precisely the same instances.

given turtle excerpt from vcard ontology describing relationship between vcard:VCard, vcard:Kind and vcard:Individual I underatand that each instance with type vcard:Individual has also type vcard:VCard
what then solid-contacts means by solid-hacks:hasIndividual

<> a vcard:VCard ;
  solid-hacks:hasIndividual <#card> .
<#card> a vcard:Individual .

elf Pavlik @elf-pavlik Nov 20 16:32
https://www.w3.org/TR/owl2-primer/#Class_Hierarchies

Stating that Person and Human are equivalent amounts exactly to the same as stating that both Person is a subclass of Human and Human is a subclass of Person.

Proposal to drop the timeline property and class

Proposal to drop solid terms' timeline property and Timeline class.

Intended semantics and usage overlaps with https://www.w3.org/TR/activitypub/'s Outbox: https://www.w3.org/TR/activitypub/#outbox - which is basically a container/collection of activities. There is also a growing list of applications/servers that implement https://activitypub.rocks/implementation-report/ , hence more likely to work interop with.

In contrast tot as:outbox, solid:timeline for instance is underspecified.

If there is nothing mission critical or great adoption, I suggest favouring/encouraging the use of as:outbox instead of solid:timeline.

If you are using solid term's timeline in an application, please indicate if it is actively used or still in working condition along with the URL to the application. If you are against the proposal to remove, please indicate if/why solid:timeline is preferable to you over as:outbox.

Typo in flow vocab

There is a typo in the following vocab:

http://www.w3.org/2005/01/wf/flow#

As we dont have a repository for this vocab it was suggested to raise it here.

Poperty should be renamed to Property

It would be great if someone could help

Idea: Solid App install

ontology info that can be used by an installer on a solid server, to automate the installation (and presentation) of a new app.

Add solid:objectivePronoun, solid:possessivePronoun, solid:subjectPronoun

Strings for a person's preferred objective, subject, and possessive pronouns.

Expected rdfs:domain for the pimspace storage property

re: http://www.w3.org/ns/pim/space

ws:storage     a rdf:Property;
     :comment "The storage in which this workspace is";
     :label "storage";
     :range ws:Storage;
     owl:inverse  [
         :label "workspace included" ] .

To me that seems like the rdfs:domain of ws:storage should be ws:Workspace, and used like this, e.g:

<http://example.org/workspace/>
    a ws:Workspace ;
    ws:storage <http://example.org/> .
<http://example.org/> a ws:Storage .

However, all the uses that I've come across attach it to foaf:Agent, e.g:

<http://csarven.ca/#i>
    a foaf:Agent ;
    ws:storage <http://example.org/workspace/> .
<http://example.org/workspace/>
    a ws:Workspace .

@timbl @deiu The wording in the rdfs:comment is throwing me off, would you mind clarifying. I don't see how it should be an agent's property. There is no rdfs:domain defined for the property so, in practice anything can go in there but, what was the original intention?

how PIM and LDP relate to VOID?

• http://www.w3.org/ns/pim/space
• http://www.w3.org/TR/void/

Linked Data Fragments has VOID as informative reference

• http://www.hydra-cg.com/spec/latest/linked-data-fragments/#datasets

Few observations and questions:

• void:uriSpace seems similar to ws:uriPrefix
• can nested ldp:Container can have void:subset relationship?
• can one use void:classPartition with ldp:Container? (similar question on Hydra API mailing list

I will try to add more comments here in next days!

Property to indicate master or preferred storage

A profile may have multiple pimspace:storages, and it is not clear for applications which to use - it can be arbitrary in every use. So it'd be useful to be able to declare the master or preferred storage space e.g., with property pimspace:masterStorage or pimspace:preferredStorage. This is along the lines of pimspace:masterWorkspace.

Property that indicates how much disk space is used in POD

As an extension of #29 and an solution available for nodeSolidServer/node-solid-server#918, we might need a property that denotes the total size of all files in a given POD. Do we want to introduce this property, and what should it be named?

Building on #35 I propose the property solid:totalFilesSize.

An example (that could be used in serverSide.ttl):

</> solid:totalFilesSize "13000"^unit:Byte

should wac ontology be given an https base?

Given that the acl ontology is now redirecting permanently to the https url, should
that be the new base?

curl -i http://www.w3.org/ns/auth/acl
HTTP/1.1 301 Moved Permanently
Location: https://www.w3.org/ns/auth/acl

There are good reasons to have a security vocabulary served over a secure channel...

Default license to use

app ConfigurationFile can have a property to indicate the license that the user when creating content/media with that application.

The user can also have have a default license of their choice which they'd like use when creating/remixing content.