Extract frontend components in a separate library

[srosset81]

Once the data provider and auth provider will support "regular" Solid servers, the frontend components will be usable by any Solid developers.

I think it's the good time to split the backend services and frontend components from SemApps, which cause confusion, since it make people believe that the two need to be used together.

So I propose to keep "SemApps" as the name for backend services, to find a new name for frontend components and to move the frontend documentation to a new Starlight-based website.

What name shall we use ?

Ideas:

• Linked Data Framework (but already used here ... besides LDF is also the acronym for Linked Data Fragments)
• FI-LD (Framework for the Integration of Linked Data)
• ...

Ping @simonLouvet @fluidlog @VincentFarcy @GuillaumeAV (we are requesting funds from NLnet for this issue, amongst others)

Related issues

• Rename semantic-data-provider to linked-data-provider #1218

[srosset81]

Found out that the following domains are available for around 10€ a year:

• ldframe.work
• ldframework.org
• ldframework.io
• linkeddataframework.org (a bit long IMO)

ldf domain names are generally not available, or cost more than 150€ a year. The https://ldf.js.org domain is also taken by a project that is not updated since 2019.

[GuillaumeAV]

If you receive funds I want to be paid for my contribution on the brainstorming for the name ! SemApps could be used for the frontend component no? And we could have SemBack for the backend ? We also had Linked data management system .. Le mer. 22 mai 2024, 15:34, Sébastien Rosset ***@***.***> a écrit :

…

Once the data provider and auth provider will support "regular" Solid servers <#1121>, the frontend components will be usable by any Solid developers. I think it's the good time to split the backend services and frontend components from SemApps, which cause confusion, since it make people believe that the two need to be used together. So I propose to keep "SemApps" as the name for backend services, to find a new name for frontend components and to move the frontend documentation <https://semapps.org/docs/frontend> to a new Starlight <https://starlight.astro.build/fr/>-based website. *What name shall we use ?* Ideas: - Linked Data Framework (but already used here <https://docs.plm.automation.siemens.com/content/polarion/20/help/en_US/teamcenter_polarion_integration_installation_43/solution_components/configure_the_teamcenter_linked_data_framework_ldf_component/overview.html> and here <http://silkframework.org/>) - FI-LD (Framework for the Integration of Linked Data) - ... Ping @simonLouvet <https://github.com/simonLouvet> @fluidlog <https://github.com/fluidlog> @VincentFarcy <https://github.com/VincentFarcy> @GuillaumeAV <https://github.com/GuillaumeAV> (we are requesting funds from NLnet for this issue, amongst others) — Reply to this email directly, view it on GitHub <#1256>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABO75HAM7OAWPKIJHBHC4HTZDSNE7AVCNFSM6AAAAABIDVKQ6OVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTANJVHAYDCMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[srosset81]

If you receive funds I want to be paid for my contribution on the brainstorming for the name !

Your contribution is priceless ! ;-)

SemApps could be used for the frontend component no?

I find the name SemApps to be confusing, as we don't know what "apps" we are talking about. Also "semantic" is less and less used, except in academic fields.

[simonLouvet]

key words

• Linked Data
• React Admin
• User Interface
• Framwork
• semantic

I try to put them together

• LIDIF : LInked Data Interface Framework

[srosset81]

Following the discussion on the 22th of October with @nikoPLP and @Laurin-W, I came up with this idea:

The framework should be framework-agnostic, with several layers.

flowchart TD
    A(Core functions) --> B(React components and hooks)
    A --> C(VueJS components)
    A --> D(Svelte components)
    B --> E(React-Admin data provider)
    B --> F(Refine data provider)

Loading

The core functions would include basic data fetching stuff such as getOne, getList, etc. But also real-time subscriptions (via Solid notifications or NextGraph pub/sub) and containers detection (via VOID, TypeIndex or SAI)

The React layer could include components and hooks that can be used without React-Admin. This is where we would put the current ActivityPub hooks (useCollections, useInbox...).

The React-Admin layer would include a React-Admin-compatible data provider. If it is used, then we can use all the React-Admin hooks (such as useGetOne) as well as the large amount of components. But we will not be able to use live updates, since this is a paid feature of React-Admin.

A Refine data provider would probably not be a lot of work, and would open to another community of developers (there are as many stars on GitHub for Refine than for React-Admin). Plus Refine provide tools for live updates, without needing to pay more.

[nikoPLP]

Sounds very good!

And in NextGraph implementation of those core functions (for those who want to use directly nextgraph APIs) will not be based on solid notifications but on nextgraph system of pub/sub.

We share work on those core functions definition together.

Also I am planning to add another "derivation" of those core functions into the react store system for nodeJS/Deno called Valtio, for developers who want to do some services based on our "unified framework"