Volunteers needed for SolidLoV App

I need to look more into how a distributed ontology network would work. This would be fundamentally different than just having the LOV database or triple store on a pod, so it needs thinking about. There are things out there like SAFE and IPFS that might be relevant.

It may make sense to have phases of development where the first phase is a triple store on one pod.

The road is not clear. If its a community project then it would be better if we could decide as a community, decide about the above as well as where the repository lives. I’m not really sure how community projects work.

1 Like

@anon36056958 This could be a great moment to apply the concepts of Solid on the Linked Open Vocabulary. LOV is more than just the code behind. It is also a community of people sharing good quality ontologies, a service to automatically track and interlink those vocabularies and different ways to use the data (dump, SPARQL and API)
Here is a brief summary of LOV:

The LOV initiative gathers and makes visible indicators that have not been previously harvested such as the interconnections between vocabularies, version history along with past and current referent (individual or organization). The report details the various components of the system along with some innovations such as the introduction of a property-level boost in the vocabulary search scoring which takes into account the property’s type (e.g rdfs:label, dc:comment) associated with a matching literal value. By providing an extensive range of data access methods (full-text search, SPARQL endpoint, API, data dump or UI), the project aims at facilitating the reuse of well-documented vocabularies in the Linked Data ecosystem. The adoption of LOV by many applications and methods shows the importance of such a set of vocabularies and related features for the ontology design activity and the publication of data on the Web.

LOV architecture is presented in the Figure below: lov-archi.
For those who have time to go through the full paper describing LOV, please follow this link.


I’m very glad to see you here @gatemezing and explaining more about LOV. I liked it very much when I stumbled on this, but have not done more than scratch the surface so far. As mentioned, I have ideas for building using the data you have created, and on the APIs which I looked at. I think you are doing valuable work.

One of my questions which your presence is helping with, was should I build stuff using LOV?

Because with any web service it is hard to know if it is being maintained (clearly it is!), and if it will be around in the longer term?

Your presence and enthusiasm encourages me on the last point, but can you say any more about this. What’s the future that LOV is trying to create and what are its prospects for being around in five year or more?

I’m also reassured by you saying it is really a community, but wonder if you can elaborate or answer those specific questions. Thanks!

Hi @gatemezing,
Your paper http://www.semantic-web-journal.net/system/files/swj1178.pdf is very interesting. In it is mentioned that
“Currently, LOV’s scope focuses on vocabularies for the description of RDF data and does not include any Value Vocabularies such as SKOS thesauri. By making the code of LOV system open source, we encourage anyone to set up an instance of the system to target such artifacts.”

Can you explain what a ‘value vocabulary’ is? Thanks!

Hi @anon36056958,
Regarding your question, the target of LOV is really about “ontology” in the sense of W3C OWL definition. In that sense, SKOS is an ontology which is present in LOV. However, thesauri which as instances using SKOS are what we call “Value Vocabularies”. They are also taxonomies using an ontology like SKOS to structure their content.
Basically, ontologies are created with this triple <myontoUri> a owl:Ontology .



Hi @happybeing, it’s a pleasure to follow this community.
Thanks for both your comments and questions.
You can build stuff using LOV, and there are many services using LOV as backend. Of course, depending on your use case, we’ll recommend using either the API or the dump; not the SPARQL endpoint. Some of the applications are listed in this page under “Application Ecosytem”
Regarding sustainability, LOV has been around for almost 8 years. Regarding hosting, LOV was hosted during 6 years by the Open Knowledge Foundation.

Since July 2018, LOV is hosted by the Ontology Engineering Group at UPM. Four years after its launch, and one year after the end of its initial framework project, LOV is supported by a small team of curators and developers.

Our goal is to have the service available again for many years, as long as we have the support of institutions like OKF or UPM.



I’m thinking of trying to make an initial version of a SolidLoV app that does the following:

  • puts the LOV database on a pod (of the users choice) in HDT form (binary format for rdf) if its not there already

  • allows the user to edit (with a simple text editor) and run Sparql queries over that using Comunica

If this sounds like a bad plan please let me know. It will take me a while doing this because I’m kinda slow, eh? Unless there are Volunteers


Cool, I like the approach @anon36056958!
Small comments to understand the use case:
1- Is the user also able to decide if he/she takes a small (subset) of the LOV database?
2- When you say “edit the database”, you mean she/he can include more vocabs? That’s cool! It gives the “power” to the owner of the vocabulary to manage and/or curate the entry in her Pod. We can even think of sending a “push” to the public pod? (if such thing exists) to say to the community…Hey there, my version of SolidLOV contains more categories or vocabs.

Let me know where to start regarding the resources in creating Apps with Solid. Thanks!

1 Like

Sounds great @gatemezing!

This needs more thought, but I’m imagining the following phases of development for this project, which I see as a sort of content delivery network of pods for delivery of ontologies, shapes, forms, and other rdf things. This is just dreaming so far :). Feedback is definitely welcome.

  1. Make an app that clones the entire LOV database in compressed HDT format to a pod of the users choice and then with the app the user can run Sparql queries on that.

  2. Make the app able to store selected parts of the LOV database, and possibly other rdf things such as shapes and forms, etc. that can be queried and updated. Call this the origin database. It can be used for ontology lookup and tagging, property and class autocomplete, filling forms or checking input, or other things. Have a Solid group with its own server and WebId that can configure and approve additions to or evolution of the origin database. Call the pod with the origin database the origin pod.

  3. Find a way to replicate the origin pod, either using the whole origin database or some part of it, to either a new pod or as an addition to an existing pod. Call this new or updated existing pod a dynamic content cache pod.

  4. Find a way for apps to find or request or make dynamic content cache pods, use them, and also update them from the origin pod when new things are available.

  5. Find a way for apps and/or dynamic content cache pods to push changes back to the origin pod and find a process for those changes to be approved by the administrators of the origin database.

  6. Find a way to use dynamic content cache pods as new origin pods which can be administered by their own groups and replicated and which can pull or push changes upstream or downstream.

I don’t know what you like to use for creating client apps, but there is a React app generator for Solid that hopefully will make things easier. I was planning to use that to start. Its at https://github.com/inrupt/generator-solid-react

This is a good page with some good links: https://solidproject.org/for-developers/apps

1 Like

Regarding where the repository for SolidLoV should live, these are some ideas:

  • a repo in the solid.community group on gitlab

  • creation of another solid related group on gitlab or codeberg.org, such as solid.forum or solid.users or similar name

  • a repo somewhere under a LOV related group

  • a repo under the name of a contributor on codeberg, gitlab, or github

  • the solidground (great name -ed) repo in the fullcircle group on codeberg.org as @aschrijver suggested

  • ?

A related question is if in the first two cases it could use the solid logo or a variation of it (maybe combining the LOV logo), or in the 3rd case if it could use the LOV logo

1 Like

You can adapt the Solid logo any way you wish. It has a free license: File:MIT's Solid project logo.svg - Wikimedia Commons

If the choice is made for solidground as project name then the logo could be lightgreen with a line drawn under the lower 3 sides of the hexagon with some whitespace between the hexagon itself, like it is grounded in a pot.

1 Like

Solidground, that is a really cool name as well as the symbol you mention. Is it ok with you if we use that name and logo (I’ll check with @gatemezing too) wherever the repo lives?

Yes, it is, but then you should refer to it as just the solidground project (lowercase) if you will, not Solidground LoV or SolidGround LoV App or solidground app. KISS without confusion :wink:

Also note that I may still have fullcircle solidground living at its url solidground.work so that’s a nameclash then.

PS. The color #6c0; looks nice for the logo and is a standard color of LibreOffice, called ‘Yellow green 4’ (I like to choose from there, and it makes editing docs easier)

1 Like

Probably we should stay with SolidLoV to avoid confusion. We will figure out where it will be hosted.

So many ideas here. My top 3 preferences would be:

  • (1) a repo in the solid.community group on gitlab (if that’s feasible at all, don’t know what are the requirements)
  • if (1) not possible, we can go for another solid related group
  • Finally, a repo under the name of a contributor somewhere could be another option.

+1 to have a combined logo of solid and LOV one.

1 Like

Hi @bourgeoa,

As @gatemezing suggested above, we would like to ask about the possibility of having a repository for a SolidLoV app hosted as a community project on solid.community on gitlab.

The main reason we think that’s a good idea is that we have clearly called for volunteers and feedback on the solid forum, and as contributors we will welcome contributions and feedback from all those with an interest in expanding the Solid ecosystem. In addition, this project is related to the Linked Open Vocabularies initiative, which is another important open source project in the area of Linked Data. Initially we plan to make the LOV database and vocabularies available on pods, and the project will evolve from there, initially with the idea of making a content delivery network of pods for delivery and evolution of vocabularies and other RDF resources.

Please let us know what you think. Thanks!

@melvincarvalho just now on gitlab:

Primarily our aim is to provide a stable pod for people to try out. But, you’re very welcome to use this site for community related initiatives

So that should be a good option.

1 Like

Is there an unlimited amount of space in a pod? Do we choose to store the dataset by default in the public space? or the user can decide where to store the database in her pod?

It depends on the pod. If someone hosts their own they can use as much space as they want, but I think most people will use a pod provider. The solid.community pod server default I think is 25mb per pod, but other pod providers are talking about as much as 1gb. There are no fixed limits within a pod itself that I’m aware of.

Where the user should store it is a good question. I think they should be given the choice to store it where they want but we should provide some sensible defaults. The Interoperability Panel is working on a spec for interoperability, so we probably should abide by whatever guidelines they have. I think to start, since it will probably initially be read only and be the complete database, somewhere in the public space would be good. When we get to the point where they might be choosing parts or changing parts they will probably want more privacy for it.

Good to know. I’ve just converted in HDT the current version of LOV dump. It takes 19mb in the disk (so it can be uploaded in the solid.community pod server). I put a copy here if it helps. I can imagine adding a a HDT dump in LOV space from now on. In terms of statistics, it contains the following
Total Triples: 937279 Different subjects: 192782 Different predicates: 1401 Different objects: 367694 Common Subject/Object:147908
It’s clair that LOV dump in HDT is 7x smaller than the LOV NT dump.