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
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.
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.
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.
What specific use case do you have in mind? If I understand, you suppose we have 2 or different pods with subset of ontologies, and they are kind of interacting? Maybe we can start to see how to model the fact that we upload lov.hdt in a public space of a pod for querying and share the results ?! <mylovCopyinHdt> a solid:TypeRegistration ; solid:forClass dcat:Catalog; solid:instance /public/catalog.hdt; ...; ...; .
Currently the client (GeoPub) only supports liking, but you can like your favorite ontologies (after authenticating with a Mastodon or Pleroma server).
That is really great, thanks @pukkamustard! I will check it out.
I think it would be useful to take that or the general gist of it and try to make a (gulp) solid-pane from it.
The main thing I think is that these things, ontologies, shapes, even classes and properties therein can have their own ācommunitiesā which of course will be very fluid.
The advantages of solid-panes are that they will have a high level of integration and so be more powerful, plus they may at some point be driven by ui ontology forms. Iāve been watching all that and its very much in flux and involves a learning curve, though. Then once a rdf/ontology/shape solid-pane that can do basic things is going then all the other things like efficiency, versioning, comparing, visualizing etc can start to happen.
These are big challenges though, way too big for me alone, and Iāve got to gradually get back into development mode if I can. Volunteers are definitely welcome.
