Re: Writing v1.0 of the Solid specification

+1

An initiative of excellence :)

i've notated in <rant> tags some complex issues, with apologies for the
length.  I've been working to address the underlying substance of these
highlighted points; although, not ready to easily relay the derivatives of
that work yet.  working on it.,


<rant>

Few initial ideas / somewhat structurally communicated considerations. After
drafting this email, i am considerate of an underlying question about what
/ where, is the proper realm for knowledge systems engineering. If it could
be understood as to consider that the traditional, historical role of W3C
relates in-turn to Information systems engineering; perhaps it is now
therefore the case that knowledge systems engineering does in-turn have an
array of specific qualities that are distinct to the more broadly accepted
role of W3C with respect to engineering tasks that relate to royalty free'web
standards'.

There are aspects relating to Open-Data & data format harmonisation that
would traditionally be the subject of works by organisations like the open
data institute ( https://theodi.org ). Where 'standards' are being
developed this may in-turn support the means for their works, such as
https://theodi.org/article/huge-appetite-for-data-trusts-according-to-new-odi-research/
 to grow - but without necessarily capturing the provenance frameworks
relatingwork to other moral standards.

Similarly the Web Science Trust ( http://www.webscience.org/ )works to
address other aspects that may relate well to this project and the means to
forge useful, technical specifications;  but the same sorts of issues also
apply to any melting-pot that be usefully applied for purposes of economic
relevance.

So, i'm not entirely sure how to address this overarching problem; whilst
now therefore, highlighting it once again.  Imagine what the impact may
have been should the means for a person to hold, independently, right to
have a bank-account and related assets (ie: title for property / a house)
was never brought about; perhaps, due to the inconvenient nature of its
impact on what would likely have been an environment where human activity
was undertaken at a time of feudalism.

There is a higher-level objective problem that is not dissimilar.  There's
a difference between a 'knowledge based' economy, and a 'resource based'
economy; of which, as (perhaps often) unpaid resources - your 'work' is
distinct to the data about 'your life', and whilst we could more simply
leave the problem as to be adjunct to the journey of writing and protecting
specified traits of the solid specifications as to provide the capacity for
future crispr babies to be implanted with neuralink (
https://web.archive.org/web/20181129004945/https://www.neuralink.com/ ) like
devices; on the basis that they're 'improvements' can be funded via a
licensing agreement providing the ability for a provider to sell the data
(coming from a 2 way interface);  i'm fairly certain - there's some bigger
issues at play that should be brought out of the shadows, rather than left
to be illustrated in specification documents as a consequence of not having
found means to address the real-world issues.  If the idea of web-slavery
is too hard to address today, well, the issue of addressing slavery has
always been an issue; but this time, it might be that cyber-functional
crispr baby whose consciousness is sold, for life, as an economically
beneficial option over 'freedom of thought' off the back of work as solid
contributions.

This video containing some excepts from re:publica 2012
https://www.youtube.com/watch?v=9zXqHIJJVxk should help illustrate some of
these considerations.  At the moment, these sorts of problems aren't really
related to some neural-implant; as such, talking about it generally isn't
dissimilar to talking to average people only, say, 13 years ago - about the
role smart-phones now have (given, iPhones aren't that old, so, at that
time - it's all about the future, as far as most are concerned).  As was
highlighted in the re:publica clip, the problems in the present relate
moreover to people putting their dreams in the search-box; or those that
relate to an extension of a 'resource based' approach, to solving the
economic problem of finding a means to make humanity important, or moreover
as a group - making humanity more important than the present-day desires of
the things made by man.  ie: https://www.youtube.com/watch?v=Vo6K-bPh39M

Now; given there's assets that clearly illustrate TimBL speaking of such
things in 2008 (for example) https://www.youtube.com/watch?v=HeUrEh-nqtU | I
do not see why it should be allowed that the major W3C members be furnished
any opportunity to support a world where they may possess crispr babies as
a means to improve their bottom line; and i'm not mearly talking about the
vulgarly direct example outlined above, nor have i searched for any patents
that may relate to it.  I'm just not interested in that sort of future, and
i'm not interested in doing work for free at personal sacrifice towards the
means for others to create any-such thing, as may occur due to negligence.

I raise this point now; as to say,. the specifications are very important -
but i think also, there's some particular qualities relating to these
specifications, that haven't been brought about yet - for a bunch of
reasons that some must have considered to be important.  So, this needs to
be addressed - and imho - those who wanna fight it, should be publicly
exposed.  Such sentiments have been expressed in terms of how i've been
dealt-with via github, and so, 'rule of law' means such forms of expressed
behaviourally delegated practices should be equally applied to all.  This
in-turn also kinda means, if it can't be applied to all equally - then it
should not be considered a form of 'knowledge' to suggest in any way it
does.  This in-turn relates to dignity, a dignity enhancing approach to
solid specifications is essential (imho) and this in-turn brings forth a
need to address some 'web science' attributes; or, the need to expressly
exclude them by consideration and purposefully applied 'informed consent',
by those making the specs.

</rant>

1. Contributor agreement

Fairly sure adding the w3c cg contributor agreement should cover this off a
big portion of it?

Perhaps the implication is about formal additions being supplied via the CG
or related apparatus (i.e. the specified github repo, that should in turn
note the w3 solid c.g.)

NB: It would also be good to ensure the approach doesn't version people
out.  The inception works have different qualities to incremental iterative
growth and development works, which often also require different skills...

2. Open web license & licensing "safe harbour"

Open web license Looks awesome.  Has this ever been used with a w3c
incubated project?

Does the director need to sign off on the approach? Would it help ensure no
future problems emerge, as far as may be brought about via w3c endorsement
of approach, etc.

<rant>
Perhaps there's a way to address some of the more complex issues as 'to do
items' that have been identified, whilst a solution to them isn't
pragmatically in-place as to resolve a 'fit for purpose', versioned,
outcome.  Therein / thereafter, some form of 'sense making' commitment by
W3C (and if/as required or considered beneficial, perhaps a body of members
who are committed to some set of principles, such as those being incubated
and curated via https://contractfortheweb.org/ ) could help?

I personally believe in a future where micro-payments help pay people who
do work.  This is like the idea that people are generally paid to do stuff,
like building public libraries; whilst the practice of building civic
infrastructure, doesn't provide the means for private organisations to
charge for the use of them in perpetuity, nor do private operators maintain
custodianship over the operation of that civic/civics infrastructure
'thing'.

Whilst https://en.wikipedia.org/wiki/Eight-hour_day#Australia occurred in
relation to projects that generally had a single legal personality who was
to become the custodian for work-derivatives of stone-masons and the like;
 the web, has billions of humans, and perhaps (more than) trillions of
things ranging from those sorts of things that are part of what is
life (microscopic
and macroscopic); alongside those that are not, and their 'things', such as
documents, etc.

So, how could modern tools be used to improve support for new types of
employment world-wide; and how could that work relate to the capacities of
a world that incorporates meaningful utility of a good 'solid' spec,as may
be produced by civil society incorporating support for socio-economics;
rather than potentially competing with some alternative produced to better
support the core-drivers of governments, and their capacities to support
civic/civics (and commons) infrastructure in the cyber interoperable realm..

A solid pod isn't very useful in isolation.  So, as we're defining specs -
how do we ensure we've figure out the means to support a defensible 'safe
harbour' for so doing.

Is there some sort of 'preamble', or do we leverage what's already in-place
with json in its license that says "The Software shall be used for Good,
not Evil." https://www.json.org/license.html

Fairly sure, particularly for the unsophisticated, there's a bunch of work
in here that's a. potentially worth alot of money; and b. is likely to be
considered (particularly by unsophisticated actors) to be entirely a risk
to the business models or 'vested interests' in various alternatives that
exist today. Whilst regulation is being discussed (through a lens that does
not easily understand or comprehend new options, that solid may uniquely
bring about)without it, there's various fiduciary duties that may cause
issues with various stakeholder frameworks; so, what's the best method to
avoid as much of that nonsense as possible, whilst ensuring good work is
equipped with good hygiene, as to ensure things (whether it be brand-names
or key entities, those involved in key entities, or the works of those
involved) don't get subverted.

Today, imho - it's commonly the case that 'bad actors' can go do a bunch of
damage, for strategic purpose, and by the time it's done; the means to
illustrate how the bad-actor was a bad-actor is neither able to occur due
to damages withstood; and, those involved in these sorts of attacks,
particularly if done by sophisticated actors; are then able to subvert the
framework as to suit their means.    Where this sort of tactical reality is
applied in very sophisticated, short-term vs. long-term competitive
outlooks; IMHO- it's an important thing to consider, and underlying it all
are a set of actors world-wide who care mostly about (socio-) economic
stability and the means for populations of homo sapiens to thrive in a
sustainable natural world.

Given todays informatics structures are globally centralised (i think
there's about the same amount of christians in the world, as there are
active monthly facebook users, noting, not all christians are active
monthly participants).  A prior example may be considered to include that
of some issues that emerged with web-payments:
https://lists.w3.org/Archives/Public/public-payments-wg/2016Mar/0178.html

The design of solid (and implicitly therein, the means to ensure
constituent object parts are 'fit for purpose') directly impact an array of
UN SDGs. So whilst workers continue to be horrendously under-funded, for
reasons beyond the means of influence by contributors at this juncture;
 there's some important issues that shouldn't be ignored, and imho - much
like wisdom, or considerations of quantum processor enabled futures - some
things are better left in ones head, now and into the future. but these are
choices, that do not necessarily need to be made in the same sort of way;
if, we're able to ensure 'safe harbour'.   (noting, i think wisdom should
always be in a persons head, its' the fractals of knowledge that can be
encoded in a knowledge system, which is entirely different in informatics
design to those of information - spouting systemic issues impacting our
entire planet and all species, not just homo sapiens, or so we were once
called in an economically sustainable prior age).
</rant>
3. Implementation modals?

Not sure if "modals" is the right term.  In 2001, a marketing guy working
on a project that was part of my heritage - spoke about the concept of
'intel inside', therein, there's an ecosystem of projects / works /
'things' / services, that could have a branding strategy that relates to
the concept of future labelling that might show something supports solid in
some way.  It could be a browser, that's got solid baked-in; or it could be
a government website issuing verifiable claims, that are able to be used
with solid-pod; or an 'open banking' related neobank, that supports solid
in its informatics models (noting most people, don't want to know about the
code format, etc).

Perhaps an illustrative diagram may help explain the underlying concept of
future 'solid ecosystems' & related informatics environments; stuff like
https://www.webizen.net.au/wp-content/uploads/2018/10/infosphere_actor_objects.svg
  or
https://www.webizen.net.au/wp-content/uploads/2018/09/Credential-enabled-Identity-5.svg
 (noting, both have errors that those who understand the semantics should
be able to see; and, both are old, the cred identity one is quite old, and
i consider neither to be representative of the qualified 'solid spec', but
rather are illustrated here for illustrative purposes)

As the design seeks to provide visibility (fit for purpose configs) in an
interoperable (linked) environment.

3.1 HOST MACHINE QUALITIES
There's a difference between the specs required for embedded / IoT (web of
things) implementation, vs. Smart phone vs. Desktop vs. Personal server
(i.e. infrastructure form, perhaps as a low spec'd VPS) vs. Enterprise
(i.e. POD hosting provider),

3.2 HOST AGENT QUALITIES
There's a difference between a POD service and a POD related service.  An
easier way to explain this would be to note the dependencies that exist
between existing LOD related services, and the ability to produce useful
solid pods.

Therein, for instance, vocabularies and implicitly therein - the underlying
data-services - are made to be usefully interoperable as ontologies
that are published
in a particular way.  (semweb)

Considerations include;
- RDF and/or RDF/Sparql rather than traditional APIs.
- WebID-AUTH (OIDC, TLS, etc.)

Thereafter, there's an array of related use-cases that likely need to be
communicated in some form of interop spec perhaps?  not sure how to go
about it.

Considerations include;

- Verifiable Claims - means for authoritative instruments governed and/or
issued by 3rd party to be used by POD owner.

- Entity extraction & discovery related services - for instance, extension
of works relating to sparql-mm (https://github.com/tkurz/sparql-mm |
https://www.slideshare.net/thkurz1/www2015-lime-sparqlmm )

- Data sources that are not natively HTTP. (ie: seeking that alternative
protocols provide support for a URI). Therein, those working on projects
that use alternative protocols natively (ie: DLTs) - what's required for
them to be 'solid compatible' or interoperable, or whatever the term used
to describe ecosystem interoperability.

4.  Solid presents an array of innovative opportunities that are not simply
technical in nature, but moreover bring about socio-economic opportunities
that i've considered to be instrumentally supported via the creation of
work such as solid. This has in-turn led to spending a fair bit of time
working to figure out how to communicate economic opportunities that are
brought about by solid, in ways that shift the opportunities matrix in ways
i think is important.

in so doing; what i'm finding, is that there's a very large pool of tools
designed to use JSON & GraphQL.  Conversely, i'm finding it difficult to
find easy-to-use tools that are built to take advantage of 'solid
ecosystem' parts (semweb).  I assume this is a far broader problem across
the community, whereby web-science practitioners are looking for ways to
'make a better world' but, there's an awesome amount of heavy lifting
involved in getting started with solid, as apposed to json/graphql
alternatives.

5. Specification strategy document

Perhaps it is the case that we could produce also, a specification /
documentation strategy document; that could in-turn be used to form
rough-consensus around how to do / support, the documentation work-flow.  i
foresee as issues that relate to innovative economic frameworks that could
(somewhere between may & would) be brought about, should the vast majority
of web-users come to employ 'pods' as part of their standard practice
methods, for interacting with the cyber domain.

I believe this is likely a constituent part of the 'philosophical
engineering' ( https://www.w3.org/2007/09/map/main.jpg )task, noting there
are important object considerations that form 'interference patterns' with
specifications design processes (such as whether or not the economics for
supporting this infrastructure is built upon a concept of 'consumers'
(humans) selling aggregated data about themselves via one or more specified
gateways; in a manner that would not have been possible due to privacy law
where that data was otherwise stored seperately, in silos;  or, whether it
is indeed the case that other business cases provide an opportunity matrix,
that could make those sorts of business models a consumer choice; and/or a
redundant pre-requisite and/or a market-based alternative that is depended
upon by some providers (and/or the devices that they may sell that
incorporate the use of a solid server, which may incorporate considerations
for use-cases such as
https://www.wired.com/story/internet-connected-sex-toys-security/ ) and
that that may offer cheaper alternatives having made an express choice
(where there is one to be made), that may in-turn require considerations
relating to retail labelling laws; that may aid consumers in future,
depending on how it is we're able to address these sorts of 'sense making'
problems now, as part of the specifications design process.


6. Introduction Text

is Probably informed by the strategy piece outlining how it is this 'brave
new informatics realm' be documented as to its objective constituents &
branch-able counterparts?


____________________________________


Happy to participate in a teleconf, perhaps after fleshing out some of the
object parts we need to review, consider and form consensus about, in
relation to any better thought out, pragmatic approach.  I'm also concerned
that i may be considered to be conflating the issues relating to writing
down the specification; which is not my intent.  therein, with regard to
the underlying object part of considering that we need the specifications
documented - Ruben - great to see how you got started on it...

Hopefully, that's helpful.

Timothy Holborn.




On Wed., 15 May 2019, 8:13 am Ruben Verborgh, <ruben.verborgh@ugent.be>
wrote:

> Dear all,
>
> The current specification for Solid is located at
> https://github.com/solid/solid-spec/.
> There are a couple of issues with this version:
>
> – It is a loose set of markdown documents, not a single, authoritative
> looking spec.
>
> – These documents are out of sync with reality:
>   – Some features that are described, are purposely not implemented.
>   – Some features that are purposely implemented, are not described.
>   – Some features are purposely implemented differently than the spec
> prescribes.
>
> – The documents leave ambiguity in many places,
>    meaning that they are insufficient to implement Solid.
>
> – Not everything in these documents has gone through a decision process:
>   – Some features might be undesirable as basic requirements of Solid,
>      for instance, for computational reasons.
>   – Some decisions were taken pragmatically some time ago,
>      but do not necessarily reflect how we want to continue.
>
>
> The reasons above should show that there is a need
> to arrive at a consistent Solid specification.
>
>
> My proposal for this is to start a new document for v1.0
> that follows the W3C specification template,
> and to use GitHub’s pull request mechanism
> to add curated sections of content to it.
>
> As a follow-up on https://github.com/solid/solid-spec/issues/170,
> I have currently created the repository
> at https://github.com/solid/specification/commits/gh-pages
> with a live version at https://solid.github.io/specification/.
>
> These curated sections would come from the current spec documents,
> but they would be rewritten to be accurate and unambiguous,
> and people in the community should be given the opportunity
> to comment on texts that get into the spec.
>
> This process will require processes for moving forward:
> https://github.com/solid/specification/issues/1
> and likely 2–3 spec editors
> (in addition to all of the past and current spec authors):
> https://github.com/solid/specification/issues/2
>
> I have also proposed this as a discussion topic for the next meeting:
> https://www.w3.org/community/solid/wiki/Meetings#20190516_1000CEST
>
> As always, feedback most welcome.
>
> Best,
>
> Ruben
>