This is a call for volunteers interested in helping to build a SolidLoV App, which looks to be an implementation of the Linked Open Vocabularies hub based on Solid, either directly or indirectly through SemApps.
@gatemezing, who is one of the maintainers of LOV, has generously offered to help.
@gatemezing, correct me if I’m wrong, but it looks like LOV uses java and sparql to put ontologies in a mongo database and then an api returns terms and persons and organizations in the ontologies.
It would be great to have a Solid version of LOV but possibly with the ontologies themselves in a triple store accessible through a Solid pod. Then it could be available to other pods or clients to use sparql queries on the ontologies to in most cases read or analyze them but also eventually, in some cases and with the necessary permissions, to update them.
I saw your question in Storage size of free pods - #6 by anon36056958 which stems from the collection of ontologies being large, right? Isn’t the idea of a centralized repository against the grain of Solid, where you want to instead have decentralization and every person contributes their own vocabularies and/or information on which vocabularies they use (and maybe cache that in their pods)?
Then there needs to be a unified way to search, find, browse this ‘web of ontologies’. This is very similar to how PeerTube works:
PeerTube is not meant to become a huge platform that would centralize videos from all around the world.
Rather, it is a network of inter-connected small videos hosters .
PeerTube is federated using ActivityPub, but…
The PeerTube software can, whenever necessary, use a peer-to-peer protocol (P2P) to broadcast viral videos, lowering the load of their hosts.
In this way, when you watch a video, your computer contributes to its broadcast. If a lot of people are watching the same video at the same time, their browser automatically send smalls pieces of the video to the other viewers. The server resources are not over-exploited : the stream is split, the network optimized.
The concept for videos is a bit different, but the idea behind it applies to sharing ontologies as well, I think.
I got no reaction to my proposal to set up a Solid community website for solid.community, but projects like this are candidates to be ‘official’ community projects. Instead of calling for volunteers these could be just started and promoted like any OSS project.
Then if Solid Project and Inrupt support the idea of a strong community next to the project initiative itself, @MitziLaszlo and community forum moderators could facilitate project development forum-side, i.e. create Categories and Groups, pin announcements, etc. here. This is how SocialHub is set up.
The big advantage is that projects by community members are not mere topics on the forum anymore, which then subsequently sink out of sight. Having real community projects will serve as an attractor to other devs to become involved in Solid.
How about SolidGround project? I could provide a project space on codeberg.org in the fullcircle organization.
(I could also provide this on github, but GH has a bit of a centralization problem itself, gitlab is going there too, and Codeberg is purely for FOSS with the right ethics and mindset of openness).
Codeberg is well-known in the fediverse. It is a German non-profit, so EU-based which is good GDPR-wise and such. The software they use is Gitea which is a very actively developed github clone.
Note: There is a bit of a #LeaveGithub trend similar to #LeaveFacebook.
Click for background on fullcircle (minimized to not pollute thread)
fullcircle is part of the open innercircles.community that I am setting up, just like teaserbot labs where I recently started the delightful project. I am planning to create a number of delightful curated lists, one of them being delightful-linked-data with the best that the semantic web has to offer. The innercircles initiative itself will be linked data based and I have a need for a collection of ontologies that match domain models of innercircles applications.
So I’ll be collecting ontologies anyway, regardless of SolidLoV App initiative.
PS. I created the solidground repository, because that name is very fitting for fullcircle. If you don’t want it to be combined with Solid it will bear the name fullcircle solidground.
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.
@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: .
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.
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!
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.
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.
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.
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.
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.
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.
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
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
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.
.
