Clarify Solid Profile conformance (cardinality) and use

[csarven]

This issue is related to #25 on clarifying Solid WebID Profile conformance and use in that it has to do with specifying the cardinality of properties.

Putting aside requiring a shape and validation mechanism for the moment, multiple values for any property can occur in RDF. So, in addition to the requirements, advisements (Notes) can mention what application developer may want to take into account when encountering e.g., multiple values for a property when only one was expected - process all, pick first, pick one at random (or flip table and go for lunch.)

In LDN discovery there was the same consideration about whether to require only one or allow multiple inboxes, and we decided on one ("A resource MUST advertise only one Inbox") as that would be the minimal requirement for interop as well as forcing the code base for senders and consumers to be simple.

Another example: In WAC, authorization evaluation is only concerned about finding whether there is a match for something or not.

[jeff-zucker]

My opinion is that we should create a data model section to be the first section after the introduction which would set out this cardinality :

A Solid Profile contains

• exactly one WebID Profile Document
• exactly one Preferences Document (space:preferencesFile)
• exactly one Public Type Index (solid:publicTypeIndex)
• exactly one Private Type Index (solid:privateTypeIndex)
• exactly one Solid inbox (ldp:inbox)
• one or more OIDC issuers (solid:oidcIssuer)
• one or more storages (space:storage)
• zero or more Extended Profile Documents (rdfs:seeAlso)
• zero or more of any other RDF predicates (any predicate)

[timbl]

Looks reasonable. Glad we won't have multiple prefs, type indexes.
I'd add for communities:

• Zero or more profile:me solid:community ?org in profile
• Zero or more profile:me solid:community ?org in preferences

[timbl]

For each storage, presumably, SolidOD should provide a tab to browse the files in each pod in the user's dashboard. Nothing else gets automatically discovered in each storage.

[timbl]

What things should be looked for in Extended profile Documents?

[jeff-zucker]

My view : It is up to the WebID owner what they want to store in Extended profile documents (seeAlsos). While they can do this for data-organization (e.g. keep all foaf:knows triples in one file), the more important use is for restricted audiences. I might want only work colleagues to know my work phone so I'd put it in a seeAlso file restricted to my work colleagues. If I had a complete storage that is only for me and my wife that I didn't want anyone else to even know was connected to me, I could put the space:storage triple in a seeAlso file only accessible to my wife and me. If I belong to the giraffesAreSexy community but don't want anyone but other members of that community to know, I would put the solid:community triple pointing to it in a seeAslo. I would put my ldp:inbox in a seeAlso if I wanted to restrict access to it. Since seeAlso files can contain any data, including important structural data such as location of storages, and inbox, it is incumbent on apps to load the seeAlso files unless they know they have already found the definitive answer to whatever question they are asking.

The way we describe things, the only triples which should NOT go in a seeAlso file are :

• rdfs:seeAlso (the app is not obligated to follow seeAlsos in seeAlso files, that could get messy)
• solid:oidcIssuer (the OIDC spec requires it to be in the WebID Profile Document itself)
• space:preferencesFile (it should be loaded before seeAlso files because it can contain triples to other seeAlso files)

[jeff-zucker]

• Zero or more profile:me solid:community ?org in profile
• Zero or more profile:me solid:community ?org in preferences

And in seeAlso files - for communities I want to share stuff with but which I don't want anyone but members of the community to know I belong to.

[timbl]

Isn't the preferences file the place for things I want to keep private? Then you can put a community link in there, and apps will see , but people won't. Then you can put things to share just with the community in the private type index of the community.

[jeff-zucker]

The preferences file is where we put things that are only accessible when it is us operating the app - it is only visible to our WebID. A seeAlso file accessible only to community members can be seen by an app operated by another community member visiting my pod. So if you come to my pod, you can see the triples in my SolidOS seeAlso but not in my preferences file.

[jeff-zucker]

These cardinalities are all covered in #40, continue discussion there, please.