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 
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.
3 Likes
Thats great @gatemezing! If you want I think you can use @jeffz’s solid-shell to upload it to a pod. I think we can use https://comunica.linkeddatafragments.org/ to query it from an app. It says on there that you can query over compressed HDT datasets.
I created a pod, lov.solid.community. I’ll DM you the password.
1 Like
Would this essentially be one 19mb turtle file in one container on one pod owned by one web id, etc ?
It will be triples in compressed HDT format, which is about 10% of the size of a turtle file and faster to access. In this form it is basically read only, because if its written then the re-indexing would be computationally expensive. These are all the ontologies in the LOV database, I think something like over 500 of them. It can be controlled by multiple web id’s, but I expect a Solid Group with one web id would administer it, which would probably be simpler than having each member of the group added as a controller.
This is early days for this and and at this point we are just experimenting. The idea so far is that some pods will have these databases for ontologies, and maybe also for shapes, forms, etc., and that they will possibly evolve separately according to their users needs. This is not a part of any specification. Exactly how this project will evolve has yet to be worked out. Your feedback and participation is welcome.
1 Like
Yes definitely agree with all the assumptions and such, one thing I’m asking regarding is moreso around guidelines and patterns and such that we can imagine given such an idealistic use case etc .
For me, this gets back to why semantic web is obsessed with single file / graph from perspective of human readability and such, versus RESTful Linked Data and Hypermedia (HATEOAS) more obsessed with machine readability, all the while people still invented and decided to use IPFS and Ethereum and etc in various ways .
My assumption regarding the idealized reality of SOLID is moreso that something like an LoV is distributed and decentralized and federated … in any reality of physical or logical organization of data etc .
It’s easy for us to right now just assume it’s all one file in one pod controlled by one account and domain and web id etc, and trust it all etc, but that isn’t at all the selling point .
I may recommend that it’s worth right now breaking stuff (the LoV) up across domains, pods, web id, etc for the mere purpose of see HOW it’s possible …
1 Like
To clarify some of my “attitude” here, consider how on other places in the forum and the chat where people debate the efficacy of writing RDF TTL or etc notation specific to a single file (and “graph” regarding blank node notation etc) versus the possible reality of it all being broken up across people and domains and etc .
What I’m moreso considering here is what is the most complex manner in which tic-tac-toe could exist on SOLID versus the provided example in the project .
SOLID shouldn’t be used merely just to store files and control access … maybe? but that also gets back to my other post on what is most minimal SOLID .
I’m down to explore! Just some thoughts flying!!!
1 Like
But its not going to be all in one pod controlled by one account. There will be many pods with possibly the same but many with possibly different databases and even contradictory ones. Because thats the world we live in, the way people are. The words you use for something in your group will be different from the words used in another group. We don’t want a stovepipe solution, we want to reflect reality even if the problems are still there.
1 Like
I agree in the overall aspect, but my reply was regarding the LoV file itself … there’s a weird grey area out there about how anything is actually community owned, as opposed to just actually owned by one id and storage and merely granted access to.
2 Likes
Yeah we will have to address that weird gray area somehow. I agree and I think the architecture of Solid, being a step closer than the current web to reflecting that reality, will help to address it.
I don’t see where you see this “obession with single file” by the SemWeb community. There are many technologies that avoid exactly the use of “single file”. LOV data can be consumed in various ways (SPARQL, LDF, API, Federated queries, etc).
I hope that we could use all the full potential of solid principles to build a more decentralized vision of sharing ontologies/forms/shapes/rdf things on the Web, as the same time preserving the incentive for users to reuse existing “stuffs” out-of-their-pod.
3 Likes
Is the issue for you centralisation (by pod, domain, owner etc)? In which case this would I believe addressed by using a decentralised backend, certainly with Solid on SAFE Network.
It was suggested recently that I come up with use cases for a SAFE Network backend for Solid (to include in one of the Solid panels) but I’m struggling to see it that way because SAFE brings a range of benefits to so many use cases. Benefits which are I believe all important to users of Sold (e.g. decentralisation, data security / e2e encryption, privacy, data ownership and control, RDF based APIs, an economy). A downside for some is no server, which is equally an upside because this delivers the features just mentioned.
1 Like
Blank Nodes are well-known to be artefacts that hinder the fully creation of a 5-star dataset.
1 Like