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 
-edit-
ok asked at https://gitter.im/solid/chat?at=5eeb7b5e54d7862dc494da20
-edit no. 2-
also asked at https://gitter.im/solid/specification?at=5eeb7f24e0e5673398be73f1
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.
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 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.
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.
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; ...; ...; .
