Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
csarven on main
Add privacy-principles (compare)
csarven on version-scheme
Add version scheme (compare)
csarven on kjetil-homepage
csarven on require-describedby
csarven on restrict-requirement
csarven on allow-delete
csarven on jeff-zucker-patch-1
csarven on allow-allow
csarven on n3-patch-def-links
csarven on triples-patterns
csarven on sparql-update-simplify
csarven on linebreaks
csarven on cache-control
@janschill That's indeed a tough one but I'll give it a shot (and others can shot me down if they like). The short answer is that the key aspects of the ecosystem are for the most "complete". There are some rough edges indeed, some nice to haves or unknowns but that's to be expected. Bear in mind that what makes a spec a spec is not just that there is a nice/readable document to look at but all the work that goes into it, anything from all supporting documents, to publicly demonstrating working implementations based on the specs, as well as actual usage in the wild. There is a lot of iteration on that front. We could call it "ready" at any point but that doesn't serve us or anyone in the end. So, to answer your question more concretely, I would say in 2021Q1, or more realistically Q2 we'll be in a position to wrap up majority of the current work and make a wide call for implementations - not to be confused with the idea that call for implementations/experiences/feedback hasn't been done already or needed on an ongoing basis. To me, the wide call marks a point where we feel the specs are mature enough and expect minimal / hopefully non-breaking changes to the specs based on implementation experience. We need to eventually get a lot of input from users - yes, that includes anyone dogfooding the specs to anyone that only needs to get their tasks done. Think along the lines of whether the servers,.. apps being developed have a net positive effect or harming users.. This is why ethical checks on the path to developing the specs are important. We don't want to be in a situation where we think we are ready for wide use - I don't mean just few isolated users or environments, but for the Web.. - and then deal with major privacy, security, ethical implications. We need to work our way up.. scale up. Don't need to have everyone implementing and using at the same time either. It can happen in phases.. gradually, so that gives us time to improve. When people developing servers, apps etc. can look at the specs and get reasonable coverage. We will weed out stuff that no one is using - and put them into the research/homework/experimentation bucket for later.
Various specs are in the works and they are at different maturity. More specs will come forward. There is no fixed "end" date or completion for the Solid specifications. Just as there is no particular end date for standardisation. W3C is still going after all for obvious reasons. The point of the Solid project is to help towards changing the course of the Web. We are learning about what's broken and propose ways to fix things.
Folks on the authorization panel might want to check out the discussion about auth from command line apps at https://forum.solidproject.org/t/authorisation-for-a-mobile-app/3692/9
Responded
@base <http://base1> .
<a> <b> <c> .
@base <http://base2> .
<d> <e> <f> .
<g> <h> <i> .
validates fine on http://ttl.summerofcode.be/ and also using Jena's turtle
CLI
<http://base1/a> <http://base1/b> <http://base1/c> .
<http://base2/d> <http://base2/e> <http://base2/f> .
<http://base2/g> <http://base2/h> <http://base2/i> .