SKOS in the Catalog

[jeff-zucker]

The Solid Catalog Dataset is an RDF dataset (which we may eventually further define as a DCAT:Dataset) targeted at listing everything related to Solid - apps, servers, people, organizations. The dataset is intended to be used by a variety of applications, including, for example, the Solid Efforts app which uses the dataset to assist authors of specifications and libraries and other technical audiences. The Solid Resources Catalog is an app based on the dataset that lives on solidproject.org pod with links from the solidproject.org website. The intended audience is the general public including funders, Solid developers, developers from other communities, individuals and agencies wanting to learn about Solid regardless of their technical background or prior knowledge of Solid.

While Solid Efforts concentrates on links between resources (e.g. a Service and the Products it deploys), Solid Resources Catalog focuses more on showcasing what is available and how each resource can be useful for individuals and communities. For example, the distinction between Penny as a Product and a Penny as a Service that deploys the Product is critical from a technical point of view but from a potential user's point of view, the fact that Penny is a Pod Management app is more relevant and says more about what Penny is and why someone might want to use it.

The details below pertain, to a certain extent, to all uses of the dataset but I am focusing on the Solid Resources Catalog and the attendant need to present things in a way accessible to those without extensive technical skills or prior knowledge of Solid.

The general approach is to define a set of SHACL shapes for the resources and an accompanying SKOS ConceptScheme to further refine the definitions. A summary is presented below.

In the summary these namespaces will be used
'ex:' an external ontology to be defined at a later date
'data:' the RDF dataset of the catalog
'concept' a SKOS concept tree linked to the dataset.

1. A Solid Resource must have an rdf:type that is one of the top level types defined in the SHACL below. Shapes are defined for each rdf:type and forms are generated from those shapes.

ex:SolidResourceShape a sh:NodeShape ;
  sh:targetSubjectsOf rdf:type ;
  sh:property [
    sh:path rdf:type ;
    sh:qualifiedValueShape [ 
      sh:xone (
        [ sh:hasValue ex:CreativeWork ]
        [ sh:hasValue ex:Event ]
        [ sh:hasValue ex:Software ]
        [ sh:hasValue ex:Service ]
        [ sh:hasValue ex:Person ]
        [ sh:hasValue ex:Organization ]
        [ sh:hasValue ex:Offer ]
        [ sh:hasValue ex:Specication ]
        [ sh:hasValue ex:Ontology ]
      );
    ] ;
    sh:qualifiedMinCount 1 ;
] .

2. For those shapes that we want to sub-categorize, we use the Dublin core predicate dct:type (styled as ex:subType in current version) to point from a shape to a SKOS concept, as is done in typical DCAT:Datasets.

:ProductShape a sh:NodeShape ;
  sh:targetClass ex:Product ;
  [
    sh:name "subtype" ;
    sh:path dct:type ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:in (
      concept:ProductivityApp
      concept:LeisureApp
      concept:PodApp
      concept:OtherApp
      concept:Server
      concept:ServerPlugin
      concept:SoftwareLibrary
    )
  ] .

3. Each concept pointed to by the dct:type predicate is part of a SKOS ConceptScheme which defines a hierarchy using skos:broader and skos:narrower. The current scheme produces a structure that can be represented as shown below. It is geared to highlighting a thing's function in the real world, rather than its technical function. Note that there is no distinction between a Service and a Product at this level. Becuase everything will have both a rdf:type and a dct:type, the records this table of content leads to will all include that distinction. We will undoubtedly be adding concepts as we go along. [note: this version is not online yet]

Learning Resources
  About Solid
  About Solid Apps
  Glossary of Solid Terms
Participation Opportunities
  Communication Channel
  Event
Pod Providers
  General Public Pod Provider
  Targeted Audience Pod Provider
Software
  Personal Productivity App
  Pod Management App
  Leisure Activity App
  Other Application
  Server
  Server Extension
  Software Library
Organizations
  Company or Enterprise
  Governmental Organiazation
  University department or unit
  Open Source Project
  Funding Organization
  NGO
People
Technical Resources
  Specification
  Ontology
  Research Paper
  Other Tech Resource

In addition to providing a table of contents for the Solid Resources Catalog, this SKOS concept tree supports decoupling the two hierarchies created by rdf:type and dct:type which allows us to support one set of terms for structuring the forms and records of the dataset and another for displaying and categorizing the dataset. For example :

Same Shape, Different Display Listings

  data:SomeIntroductoryArticle
    rdf:type ex:CreativeWork ;        # uses CreativeWork shape
    dct:type concepts:AboutSolid .    # listed under "LearningResource"

  data:SomeResearchArticle
    rdf:type ex:CreativeWork ;        # uses CreativeWork shape
    dct:type concepts:ResearchPaper . # listed under "TechnicalResource"

Different Shapes, Same Display Listing

  data:SomeChatRoom
    rdf:type ex:Service ;                        # uses Service shape (or more likely sioc:Forum)
    dct:type concepts:ParticipationOpportunity . # listed under "ParticipationOpportunity"

  data:SomeSymposium
    rdf:type ex:Event ;                          # uses Event shape
    dct:type concepts:ParticipationOpportunity . # listed under "ParticipationOpportunity"

Questions

1. Does this approach seem generally reasonable and in line with other uses of SKOS and DCAT?

2. Do you have any ideas on a hybrid skos/class approach? I have seen reference to using predicates along the line of sameAs or exactMatch to link a Concept with a Class. Also I've seen it directly such as ex:Foo a skos:Concept, rdfs:Class. or ex:Foo a skos:Concept, schema:Product.. It seems like a hybrid approach might allow us to define Concepts which are subClasses of Classes. Any gotchas or tips or reservations?

3. With or without a hybrid approach, what do you see as the advantages and disadvantages of using SKOS concepts instead of only using RDF Classes?