solid/specification

Create shapes repository

VirginiaBalseiro opened this issue · 4 comments

VirginiaBalseiro commented

This discussion started in the webid-profile specification group, and was discussed during a CG meeting. I am starting this issue in this repository so that we can discuss the creation of a shapes repository, but feel free to move to somewhere else if more appropriate. The text below is @csarven's comment on the discussion thread:

Feel free to move (copy/paste) this to a separate issue or discussion, but since the original discussion started off shape reuse, I'd like to suggest the following:

  • A single GitHub repository for shapes under the Solid org.
  • Shapes in the repository must be referred by Solid specifications.
  • Set workflow to have each shape available from a URL, e.g., http(s)://www.w3.org/ns/solid/shapes/{shortname}.

Background/Justification for the curious:

The management of the shape repository and publication can be same as https://github.com/solid/vocab . None of works there belong to a particular group but there is a process on accepting changes across groups and time. I created that repo because we needed to coordinate in an open and transparent fashion.

I'll refer to a couple of examples from the W3C to point out how ns/solid/* does not belong to the Solid CG (or any other group), because the same will ultimately apply to the publication of Solid shapes:

  • The ns/ldp didn't belong to the LDP WG (or the LDP-Next CG). When the Social Web WG requested to add ldp:inbox to the LDP vocabulary, the fundamental requirement was to show that a specification, i.e., LDN, needed it.
  • In the same way, ns/activitystreams didn't belong to the Social Web WG (or the Social Web Incubator CG) given that years later the DID WG requested the addition of as:alsoKnownAs, which was granted by showing that the DID specification needed it and used it.

There is no need to constrain the shape repository to specific interoperability between classes of products, e.g., for particular (not all) "client to client" shapes. Again, the shapes can ultimately it'd be backed by or can work with one or more specifications. So, a single shapes repository would serve as a place to eventually publish them somewhere (just like solid/vocab) but is not intended to hold any random shape.

Originally posted by @csarven in solid/webid-profile#88 (comment)

jeswr commented

Love the idea - and happy to help support the work on this in particular

A single GitHub repository for shapes under the Solid org.

I can dig out some old workflows that I have for "linting" and validating shapes in CI.

Set workflow to have each shape available from a URL, e.g., http(s)://www.w3.org/ns/solid/shapes/{shortname}.

https://github.com/jeswr/rdf-serve.js supports content-negotiation with SHACL Compact Syntax, Extended SHACL Compact Syntax + all recommended RDF Syntax's. Alternatively https://github.com/jeswr/rdf-transform.js/ could be used to do the same content-neg from a vercel edge function (which I'm currently setting up for my personal website). If there is interest in adopting the SHACLC CG spec within Solid (which I appreciate could be controversial) then I will also put effort into improving these language servers for vscode to support that https://marketplace.visualstudio.com/items?itemName=jeswr.shaclc-language-server.

  • ❤️1
elf-pavlik commented

👍 As long as we do not include any domain-specific shapes (chat, project management etc,). Only domain-agnostic shapes from a solid family of specifications would go there.

  • 👍1
timea-solid commented

As a follow up to some discussions: we now have a chat client-to-client spec github repo: https://github.com/solid/chat
Initial shape work will be done in the spec repos itself until it will be ported to the Solid organization shape repo (possibly: https://github.com/solid/vocab if you'd like).