What I meant here is what was clarified in subsequent discussion, essentially also related to a discussion I started a while ago regarding the granularity of access control regarding SOLID (but Linked Data and Semantic Web by extension) given that reference implementations (and subsequently recommended patterns and practices) focus on the aggregation / accumulation of triples into one file … whereby historically managed by means of granular fragment URIs …
it reinforces location based …
so my question here would be what do the people involved intend on being “first class construct” in the granular sense?
For SOLID, so far, given reference implementations, it appears to be one TTL file in one folder on one POD owned by one WebID .
I further completely understand your point regarding Blank Nodes, because that’s the entire complexity here as well, what is the granular first class construct …
Does that make more sense regarding your reply, or do I still sound off base?
Definitely agree, and this is the reality I’m regarding, specifically patterns and practices around how to regard resources and triples as first class constructs … very specifically reification for purposes of distributed and decentralized regarding atomic element of semantic web etc .
I’m very new here regarding SOLID implementations. I guess this view is just based on the first incentives to people to adhere to the POD concept (owning your personal data using Linked Data principles). My guess is that as soon as there will be more use cases, there will be a need to more interactions/collaborations among PODs. Something like an implementation of Multi Agent Systems (MAS), here with Agents as POD.
Thanks for your comments. I better understand your point.
Good question regarding granularity… I don’t have the correct answer. IMHO, reusing resources (terms) is a best practice, but not always satisfies the long term sustainability. So, people tend to create in their own namespaces so they can have control on. However, as a data consumer, I might need to use federated queries in my applications. But guess what? intensive use of servers cause other issues (such as accesibility or reliability). Finally, the option of giving a dump (again one TTL file) is an option… Well, the intermediate one could be to set up a LD fragment server.
SOLID could be valuable (?!) to certify/validate personal data. Imagine the case in my POD I have the statements <#me> foaf:knows <#bob>, <#alice>. I can imagine a way to send a notification to Bob and Alice where they “confirm” knowing me, and thus update each of our POD like this: << <#me> foaf:knows <#bob> >> solid:isValidated True. That could be a way to validate trusted FOAF regarding properties like friends, jobs, ORGs memberships, etc.
I don’t know much about the LOV database, but I was assuming it was in VOAF and these mappings as translated to mongoDB. Do you mean to expand on those?
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.
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
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.
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
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.