Volunteers needed for SolidLoV App

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

2 Likes

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.

2 Likes

@gatemezing maybe SolidLoV needs rethinking based on content addressed rdf and content addressed vocabularies

2 Likes

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 :slight_smile:

-edit-
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 :smile:

ACK! :slight_smile:

Hi @gatemezing,

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.

1 Like

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 Document with 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 :slight_smile:

2 Likes

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.

1 Like

Thanks, I agree. So as I understand you, its best to have a requirements repository that any contributor can file issues on, and then project members can move those to the actual requirements section of the project.

Anyway, my request for access is pending (I assume this is the same as a request for project membership), so I can’t yet create the requirements repository, or any repository afaict. Hopefully that request will go through.

Yea, it could be a requirements repo, but that is not needed. Issues with e.g. Epic + User Story labels could do just fine. Epics are the high-level ones, and broken down into User Stories that can be implemented.

1 Like