Goals of Solid?

user Pods:

• Decentralized
• Autonomous
• Secure
• Responsive
• Commodity product

What is Solid?

• LDP
• + interaction model
  • what to PUT/POST
  • create resources/containers
• + authentication
• + application infrastructure
• + package managers ("App Stores")

What is Solid to you?

• Identity – WebID, DID
• Authentication – OpenID Connect
• Authorization – Web Access Control
• Transport - HTTPS
• Interface – Linked Data Protocol
• Messaging – Linked Data Notifications
• Data Model – RDF
• Search – TPF, SPARQL, GRAPHQL

SemWeb Technologies

Resource-oriented architecture

Five star data

"The spec on a cup"

★ Available on the web (whatever format) but with an open licence, to be Open Data
★★ Available as machine-readable structured data (e.g. excel instead of image scan of a table)
★★★ As (2) plus non-proprietary format (e.g. CSV instead of excel)
★★★★ All the above plus, Use open standards from W3C (RDF and SPARQL) to identify things, so that people can point at your stuff
★★★★★ All the above, plus: Link your data to other people’s data to provide context

Emphasizes Open data

SemWeb Technologies

• How do I create a resource?
  It seems obvious that you use POST to create, but what do you POST to?
• Where can I get the list of resources that already exist?
• Which vocabulary do I use?
• Which media types do I use?
• When containers get big, how do I split the information into pages?
• How do I specify ordering?

What is LDP?

• Linked Data best practice
  LD & LOD
• RDF Resources
• REST interaction model
• Containers

Cast of characters

Linked data plus:

• LDP Resources (LDPR)
  • HTTP and RDF techniques to use to read and write linked data
• LDP Containers (LDPC)
  • A LDPR to which you POST to create new things, GET to find existing things
  • Similar to what AtomPub does for XML
• Paging
  • A mechanism to get the content of an LDPR in chunks
• Ordering
  • A mechanism to specify the order in which the content of an LDPR is sorted

LDP Resources (LDPRs)

• LDPRs are HTTP resources that can be created, modified, deleted and read using standard HTTP methods (i.e., POST, PUT/PATCH, DELETE, GET).
• LDPRs use RDF to define their states.
• You can request a Turtle representation of a LDPR and possibly other reps (e.g., XML/RDF)
• LDP clients use Optimistic Collision Detection on update.
• LDPRs set rdf:type explicitly.
• LDP clients expect to encounter unknown properties and content.
• LDP clients do not assume the type of a resource at the end of a link.

GET simple example

LDP Containers (LDPCs)

• LDPRs are HTTP resources that can be created, modified, deleted and read using standard HTTP methods (i.e., POST, PUT/PATCH, DELETE, GET).
• LDPRs use RDF to define their states.
• You can request a Turtle representation of a LDPR and possibly other reps (e.g., XML/RDF)
• LDP clients use Optimistic Collision Detection on update.
• LDPRs set rdf:type explicitly.
• LDP clients expect to encounter unknown properties and content.
• LDP clients do not assume the type of a resource at the end of a link.

LDPC GET simple example

LDPC GET updated

Re-using application's membership

PREFIX ns0: <http://example.org/ontology/>
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX ns1: <http://www.w3.org/ns/ldp#>

<http://example.org/netWorth/nw1>
  a <http://example.org/ontology/NetWorth> ;
  ns0:asset <http://example.org/netWorth/nw1/assetContainer/a1>, <http://example.org/netWorth/nw1/assetContainer/a2> .

<http://example.org/netWorth/nw1/assetContainer>
  a <http://www.w3.org/ns/ldp#DirectContainer> ;
  dc:title "The assets of JohnZSmith" ;
  ns1:membershipResource <http://example.org/netWorth/nw1> ;
  ns1:hasMemberRelation ns0:asset .

• Membership predicate is something other than rdfs:member (o:asset)
• Subject for members is something other than the container

What about non-RDF data?

Some vestigial files still aren't RDF!

• Images
• Binary formats
• Fonts
• everything else

LDP-NRs in Indirect Containers

• Not just RDF...
  non "information resources"
• Resource has metadata
• Metadata appears in Container
• Pointer to blob appears in Container

LDP-NRs in Platform-specific metadata

• Does not maintain parallel LDPCs and LDPRs.
• Levreages platform-specific mechanisms for metadata

Authentication integration

Solid leverages OAuth2 / OpenID Connect

1. Solid as the Resource Server and Identity Provider
2. Solid as the Resource Server with separate Enterprise Identity Provider (e.g. Okta, Ping, Auth0)

Both work.

#1 works with e.g. Active Directory, LDAP.

FHIR

• Fast Health Interoperability Resources
• Resource-oriented
• network (graph) of fhir:Resources
• REST protocol
• search parameters
• messaging protocol
• document & machine-readable data

Reasoning

• Capture truths in domain logic.
• Leverage that to ask general questions.
• - - -
• Avoid false-dichotomies around granularity.
• Get the computer to do stupid crap we don't want to do.

• information model
  (Concepts and Relationships)
  • Observations
  • AdverseEvents
  • Substance Administrations
  on patient Isabella Jones
• terminology model
  (Terms and Relationships)
  • Pneumonia a Pulmonary Disease
  • Serum Sodium a lab test
  • Penicillin an antibiotic

• information model
  (Concepts and Relationships)
  • Observations
  • AdverseEvents
  • Substance Administrations
  on patient Isabella Jones
• terminology model
  (Terms and Relationships)
  • Pneumonia a Pulmonary Disease
  • Serum Sodium a lab test
  • Penicillin an antibiotic

• information model
  (Concepts and Relationships)
  • Observations
  • AdverseEvents
  • Substance Administrations
  on patient Isabella Jones
• terminology model
  (Terms and Relationships)
  • Pneumonia a Pulmonary Disease
  • Serum Sodium a lab test
  • Penicillin an antibiotic

axiom:

[ owl:intersectionOf (
  [ owl:onProperty fhir:Coding.code ;
    owl:someValuesFrom
      [ owl:onProperty fhir:value ;
        owl:hasValue "69896004" ] ]
  [ owl:onProperty fhir:Coding.system ;
    owl:someValuesFrom
      [ owl:onProperty fhir:value ;
        owl:hasValue "http://snomed.info/sct"
    ] ]
) ] rdfs:subClassOf fhir:Codinng-of-Rheumatoid_arthritis-disorder .

data:

amy:Obs1 a fhir:Observation;
  fhir:Observation.code [
    a fhir:CodeableConcept;
    fhir:CodeableConcept.coding [
      a fhir:Coding;
      fhir:Coding.system [ fhir:value "http://snomed.info/sct" ];
      fhir:Coding.code   [ fhir:value "69896004" ]
    ]
  ] .

amy:Obs1
  fhir:Observation.code [
    fhir:concept snomedct:Rheumatoid_arthritis-disorder # <-?
    fhir:CodeableConcept.coding [
      fhir:concept snomedct:Rheumatoid_arthritis-disorder
    ]
  ] .

Discovery

• Footprints track constellations of Containers
  • Photos - just a container shape
  • FHIR - flat hierarchy
    Patient, Observation, Procedure...
  • GitHub API - highly-nested
• Shapes constrain individual Containers
  and contents
• Apps register themselves and their use of a Footprint.

AppStore model

• Trusted app recommendation service
• Centralized discovery
• No package management
  • Is that needed?
  • Is it possible?
  • Is it time?

N AppStores

• no monolithic app store
• domain-specific app stores
• opt in and out according to need and expertise
• nice balance between fascism and anarch

FAIR - Findable

F1. (Meta)data are assigned a globally unique and persistent identifier

F2. Data are described with rich metadata (defined by R1 below)

F3. Metadata clearly and explicitly include the identifier of the data they describe

F4. (Meta)data are registered or indexed in a searchable resource

FAIR - Accessible

A1. (Meta)data are retrievable by their identifier using a standardised communications protocol

A1.1 The protocol is open, free, and universally implementable

A1.2 The protocol allows for an authentication and authorisation procedure, where necessary

A2. Metadata are accessible, even when the data are no longer available

FAIR - Interoperable

I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.

I2. (Meta)data use vocabularies that follow FAIR principles

I3. (Meta)data include qualified references to other (meta)data

FAIR - Reusable

R1. Meta(data) are richly described with a plurality of accurate and relevant attributes

R1.1. (Meta)data are released with a clear and accessible data usage license

R1.2. (Meta)data are associated with detailed provenance

R1.3. (Meta)data meet domain-relevant community standards

Discussion

Can the discoverability mechansim work for scientific data?

Follow Up

• Gitter: LD chat, spec
• Eric Prud'hommeaux eric.prudhommeaux@janeirodigital.com eric+solid@w3.org
• Solid Panels:
  • authentication - https://github.com/solid/authentication-panel/
  • data interop - https://github.com/solid/data-interoperability-panel/

<BPShape> {
  :subject @<PatientShape> ;
  :code @<vs_BP-Code> ;
  :bodySite @<vs_BP-Site> ;
  :component { comp:code @<vs_BP-Systolic> } ?
  :component { comp:code @<vs_BP-Diastolic> } ?
}

<vs_BP-Systolic> @<CodeableConcept> AND {
  code:coding {
    cc:system [<http://loinc.org/>] ;
    cc:code ["8480-6"]
  }
}