@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 
ACK! 
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
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
Good to hear from you! ActivityPub standard uses the streams vocab. The link is here https://github.com/w3c/activitystreams/blob/master/vocabulary/activitystreams2.owl. We can easily convert to whatever serialization. You meant the Manchester syntax?
Hi @gatemezing,
Thanks. Either that or the Owl functional syntax, but it’s not important. I used http://www.ldf.fi/service/owl-converter/ on
https://www.w3.org/wiki/Activity_Streams/Expanded_Vocabulary#The_OWL_Definition
and was having trouble getting it to convert. I had to change every instance of ‘.]’ to ‘]’, then there was this problem https://lists.w3.org/Archives/Public/public-prov-comments/2017May/0003.html
which I hacked/fixed by importing prov-o instead of prov. Then it converted and looks plausible but I’m not sure I did it right. Anyway, I’m just using it to learn AP/AS .
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; ...; ...; .
Thanks for all the updates! I was off for holidays 
1 Like
Hi!
I’m a big fan of Linked Open Vocabularies and have been following this thread.
I have a little Demo of an ActivityPub client that can handle arbitrary RDF content (e.g. you can create, share, comment on anything). As ontologies/vocabularies are also just RDF data it works for them as well. See for example: https://geopub.openengiadina.net/browse/type/http%3A%2F%2Fwww.w3.org%2F2002%2F07%2Fowl%23Ontology
Currently the client (GeoPub) only supports liking, but you can like your favorite ontologies (after authenticating with a Mastodon or Pleroma server).
2 Likes
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.