A few to start with.

[JKReynolds]

These are some proposed use cases
Job Applications
Resume Builders
Calendar Applications
Message Applications
Car insurance Applications
Apartment Rental Applications
Loan Applications

[RubenVerborgh]

I think this PR brings good inspiration.

However, I have two concerns.

1. The language used is "The User Profile should support…". And the answer to that is already yes: profile documents are RDF documents, so they support anything you want to add to them. For instance, my profile lists articles and books, employment, etc.

2. If we were to change this to a more normative language, I think some use cases set a difficult precedent. In the sense that calendars and messages are shared by virtually 100% of all people. but loan, apartment, job, are already getting specific. So we risk ending up with a list that basically describes the whole universe, which is not Solid's job. That does not mean that Solid will not support it (again, Linked Data), but that it is perhaps not up to us to standardize.

So I think that we need to come to a small set of things that are really core to (almost) any application. And all the rest are extensions; meaningful extensions that a subset of apps can support, but that we do not need to include in a Solid vocabulary guidance document.

[justinwb]

So I think that we need to come to a small set of things that are really core to (almost) any application. And all the rest are extensions; meaningful extensions that a subset of apps can support, but that we do not need to include in a Solid vocabulary guidance document.

I agree. I think this is an excellent breakdown of the kinds of information that should be discoverable via someone's user profile, not contained inside of it.

Two things:

1. IMO, I think that this should be boiled down into one or two real world use cases that represent data associated with a given user, discoverable through associations with their identity via the profile document. @JKReynolds it would be great if you could refactor it into that.

2. I think that we should keep track of some of these common models somewhere, and start compiling shapes (and vocabs where necessary) for them. Maybe in the short term we make that another interop project. Open to thoughts / suggestions on that.

[JKReynolds]

Sure thing @justinwb I'll take a crack at that.

[JKReynolds]

My team and I put together a couple use cases that we would like to get some feedback on. Please let us know what you think. Thanks.

[dmitrizagidulin]

While we're talking about this, I do want to bring up PR https://github.com/solid/identity-panel/issues/1 which (among other things) proposes that we should separate 'user info' type data (most of which is private / access-controlled) from the public WebID profile doc.

[dmitrizagidulin]

(Which also echoes what @justinwb is saying in the previous comment, "information that should be discoverable via someone's user profile, not contained inside of it")

[mark-jensen]

@justinwb @dmitrizagidulin I am not sure I understand the distinction between data being discoverable via a user profile vs. being contained in it. The distinction seems to track one between public vs private, but if the private data is merely discoverable via a user profile, where is it "contained"?

[mark-jensen]

We have posted initial components for the User Profile use case described in this PR (link), as well as in #24, to a project repository located here

Thus far we have:

• User Profile Ontology module which extends CCO
• Sample batch of RDF for a profile
• An example of a shape for person's full name and nickname
• A spreadsheet of relevant ontology terms and definitions

Some members of our team will attend Monday's (10/21) Data Interoperability Panel call to provide a brief overview, discuss and answer questions.

[elf-pavlik]

We are going to merge this PR and move contributed file to archive directory. If you would like to continue this work please join panel meeting to discuss way forward.