Thanks for the links.
I realize that we should define a data model as instances of solid vocabulary. Let me know if you have initial ideas.
Thanks for the links.
I’m not sure what you mean by ‘solid vocabulary’.
I haven’t got as far as thinking about all that. What I’ve been thinking about is the client code to access it. There is a lot that’s needed.
We need a file or resource manager. There is the data browser but we need help to adapt it if that’s the way we want to go.
Otherwise we need a file or resource manager. The current features of Otto AA’s Solid File Manager are:
- view folder and files of your pod
- open files/folders in new tab
- upload files
- create new files and folders
- copy/move/rename files and folders
- edit text based files (txt, html, …; no special editor features yet)
- download files
- .zip actions (compress, extract)
- delete files and folders
- filter current folder (search)
But I’m thinking another one should be built for web components with something like Stencil or Svelte. Why?
Some possible reasons:
- component based
- use from html
- use linked data capable editor
- search using linked data, not just for file names
- interop with hdt
- based on comunica
- add upload capability
- add drag and drop
- render forms on open
- more linked data interop
This of course would be a big project, so it might make sense to make a subcomponent first, one that takes a path on the pod to the LOV hdt file, and a Sparql query string, and returns a result. Then the resource manager could use that whenever the resource manager is built.
Sorry for late response.
Are you still interested to open the project
SolidLoV on solid.community on gitlab ?
What exact name : SolidLov or simply solidlov or … ?
I can try to do that : it will be a first for me
Yes, thank you @bourgeoa!!
Either solidlov or SolidLoV is ok, whichever is easier.
Here it is : https://gitlab.com/solid.community/apps/solidlov
Access is public.
@gatemezing maybe SolidLoV needs rethinking based on content addressed rdf and content addressed vocabularies
Oh sorry for my late response.
What I meant here is how do we create the data model using Solid Terms according to our features. I wrote in one of the resource on creating a Solid App that it is important to thing about a data model. Maybe I’m wrong.
As far as I know there is not yet any glossary or vocabulary of Solid terms, although there is this github issue to create one.
This is very interesting, to create a model for the app based on a Solid vocabulary. I’m assuming the model would be in rdf?
Yes, there is this vocabulary (also in LOV) of Solid terms https://www.w3.org/ns/solid/terms.
And the reference to defining/mapping such things with Solid terms here https://solidproject.org/for-developers/apps/first-app/4-data-model
I had never seen https://www.w3.org/ns/solid/terms. It says it was created in late 2015 and last modified in early 2018, so its most likely out of date.
I will have my morning coffee here, and then screw up my courage and ask on the chat channels about it
ok asked at https://gitter.im/solid/chat?at=5eeb7b5e54d7862dc494da20
-edit no. 2-
also asked at https://gitter.im/solid/specification?at=5eeb7f24e0e5673398be73f1
@gatemezing. I need to step back from this for a little while, then I’ll take another look at it.
OK! Anything related to the Solid terms?
No, just need a rest. I’m an old guy
I’m working (slowly, but I’m not actually dead yet) on making an attempt at a data model for SolidLoV. It will be a mix of Solid terms and ActivityPub / Activity Streams. I’m learning about ActivityPub. If anybody knows where to find the Activity Vocabulary in owl functional syntax that would help.
So far I guess a pod, which is an Account in Solid terms, will be an Actor, and the app will be an Actor. Then I guess people will follow and like ontologies. I guess individual ontologies should be Actors?
I found this link to resources on ActivityPub, which is great.
I also recommend reading An ActivityPub Philosophy to place the standard in proper context and ForgeFed as an example of a federation protocol that is decidedly different than the most popular microblogging-based fediverse applications (PeerTube and PixelFed are nice examples of extensions to this category of apps).
Maybe at this point it is a good idea to move some activity to a repo. I am curious about the requirements for SolidLoV and find it hard to comment on e.g. what could be an
Actor and what not.
Actors per the standard are persons, organizations, applications and services (though you can define your own custom extensions, of course). They have their own inbox, outbox endpoints and follower, following, likes collections, etc. But is an Ontology an Actor? Or is it a
Relationship to other documents (i.e. the reused ontologies on which it is based)?
In Mastodon the toots/tweets are
Note and likes/favourites plus boosts/retweets are recorded as side-effects on the object.
The LoV application is very different from microblogging. It is about finding the right ontology from an ever growing archive, using them (and notifying about this so popularity can be measured), and publishing your own stuff to this archive… but my understanding of requirements is just so so
I think we can start adding requirements at https://gitlab.com/solid.community/apps/solidlov/-/requirements_management/requirements
I think to do that you need to request access to the SolidLoV project first. I think the request goes to the owner(s) of the project (which I think is @bourgeoa) or to the owner of solid.community (which I think is @melvincarvalho on gitlab)
I never used the Requirements feature of gitlab before, but it may be impractical to have anyone discussing requirements to be project members. Better may be to file issues, and once requirements solidify, maintainers transfer to Requirements board.
E.g. can have a top-level bulletpoint checklist issue, and sub issues for individual requirements elaboration.
Can you elaborate? Because…so far there are not many of us.
I’m less familiar with gitlab than github, but typically your contributors are not part of the project team. The team are the dedicated people that control project direction, very often just a single maintainer. Contributors don’t need this level of access to help the project further. Issues are open for any contributor.
Currently in this thread there are 6 participants. Once the project starts anyone may want to make contributions, however small. Do you want to request project access for each and every one of them? Do you want to have minor contributors in a team? Do you want the barrier to contribute be as high as joining a team first?
I think best-practice is to keep your team(s) small, and only add members that have shown to be dedicated contributors, who are invested in the project. Often ones that request to be team members themself.