Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add W3C Solid CG Charter #323
Add W3C Solid CG Charter #323
Changes from 11 commits
dec76ee
e71d34d
e069abf
2593f0c
790add5
4171fe4
2ba5e46
471103e
2c2eed7
7a8cfc5
b8f5be1
3a4808a
fbabbca
e9341c9
f4324e8
68ad182
e4cab8c
fafa6ea
423d03b
1b3ded2
837e124
9cadcc6
8bb0c90
2a318a4
8abb7d6
7916591
ceca2f9
b6145d2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned during yesterdays CG call, I believe these two points would be better covered under a single broader point "Data interoperability".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT: updated to include a more concrete description
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would there be also for the UI layer metadata. As in a way to allow implementation of a view without forcing a library, yet allowing one implementation that we can replace. The metadata be used in either case. (Hoping that makes sense. Unsure if that's the same as "Autonomous Web Agent")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to understand better, can you please elaborate? Perhaps a few use cases? There is some UI work in SolidOS that seems to be related to what you're saying. See also An ontology for User Interface description, Hints and Forms . I wonder if we should boost this more into the Scope. It generally has to do with what some refer to "client-client" specifications but we can be more specific on the UI aspect. Will raise this in an upcoming CG call to check with everyone in the meantime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@renoirb, I'm going to interpret some of your words; please tell me if I'm right or not.
Your question concerns some agent (I suppose some application) which would use certain metadata (about a resource) that should be sufficient to render a UI display (of that resource) without relying on some proprietary library (i.e. other than a general library for interpreting that metadata). The question then is whether the CG scope includes looking into this metadata. Is this correct?
My questions to you would then be:
Do you suppose this would require other metadata than that which describes what kind of resource we are talking about?
Can I suggest that we bring this together with data shapes and other datatype-describing-vocabulary under the denominator of 'application interoperability'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably stating the obvious. It's probably out of scope, and I guess that's the point to ask here if this can/can't be part of this.
In any situation, an implementation of a pod (e.g. Inrupt‘s Community Solid Server "CSS", or another). will most probability also have a UI alongside the programmatic data centric HTTP API. In that API there's to say what to get, and some description of what's also possible and error messages and etc.
The human readable messages be probably in a language we can configure. Probably with locale, TimeZone, what text for an identifier, and etc.
Inrupt's CSS has ways to tell where the templates are (<aside >I haven't figured out how to actually do it, the examples in docs doesn't complete how to</aside>) it's using a templating engine, etc.
I'm wondering if we could have another HTTP API context root for the backend for the FrontEnd.
We could have a way to describe how to present the lists of things, and available actions stored into the pod. It's typically lists of objects, the properties (e.g. creation date, mime-type, etc.) for each of them, actions (e.g. delete, etc.) that are different based on the context of each of them (e.g. a directory with current user having right to write can upload a file vs a file you can write on would have a "replace" action).
All that logic can quickly be deeply embedded into the UI layer and hard to separate and then limits people when making it their own. We see that often in Microsoft SharePoint, we can't theme absolutely everything. — it's complex.
What if we had a way to describe collections of view descriptions.
The description doesn't contain the objects themselves only a blueprint, not the info specific to the current user (e.g. locale, calendar, TimeZone, etc)
The descriptions could be for things like:
(I'll have to come back to continue writing this)Continued hereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The charter has a list of topics that are clearly in scope, as well as those which are out of scope. I think everything which isn't listed as out of scope is a good fit to be proposed using New Work Item workflow.
I don't see anything related to UI metadata listed as out of scope, which means that you should be able to simply propose your idea as a new work item.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you describe it now, it feels much closer to Service Descriptions again. I would urge to look into those (they have some very basic but easy to grasp examples on the website of RESTdesc). Since they can be extended with any RDF statements about some resource/service, the descriptions can be made very elaborate.
E.g. you could easily define
rdfs:label
, and anrdfs:description
to/things/
, they would be stored as anowl:Thing
, and that the response would have it's URI in theLocation
header;owl:Thing
, e.g./things/0123
, with eithertext/turtle
orapplication/ld+json
as aContent-Type
header, this would result in a response of the correct format, with the original data in the body, as well as adc:date
stating the date of creation, conforming to a specific date format;/things/
itself, you would receive a body that instead holds only therdfs:label
of everyowl:Thing
, and thedc:date
but possibly in another format; etc.And that is just for reading and writing simple resources; all kinds of form interaction and side effects could also be described.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm mostly trying to get at is that, if it's really not about display/style, but about the semantics of resources and actions on them, this is already clearly present in the scope as data interoperability; but that if this is not enough, we should maybe add something or leave you to propose something as a new work item. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do some reading. Probably read more about RESTdesc, Hydra, etc. I'll write something somewhere to reorganize this, and see.
I'll go through the new work process once I have more notes and see to use the mentioned technologies.
what if it's just me mapping what I'm trying to say, and what I've just been exposed to. Thanks.
In any case. W.r.t. scope and incubation. I might be able to make a PoC using the mechanics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing though. I make distinction between the data from a description of assembly of that data.
But describing a schema, making sure an entry matches the model is neat though! If that data is a description, just data, regardless of what's there, that's a possibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following Scope item covers a bit of the needs discussed here:
(See also e.g., structured error messages, service/storage description and use cases therein).
And we can add more to the listed examples there. Perhaps "actions"?
That aside, it'd be useful to revisit emphasis on class of work towards building smart(er) clients (Application, UI) in Solid that says a bit more than vocabs/data models/shapes/service descriptions/client-client. I'm in favour of a specific Scope item capturing "UI" or "Application". (Ditto what can capture for example the UI ontology). I find the term "Interoperability" too broad - after all, all these efforts are towards interop. But, interop between what and what product as far as conformance is concerned? (see Solid QA work). Variability in Specifications for instance generally mentions classes of products like Consumer/Player/Processor which may be closely related here.
I made an imperfect suggestion here https://github.com/solid/process/pull/323/files#r1277302683 , please review and suggestions towards what's intended if it is not adequate.
I suggest that we resolve this discussion soon. It is a touch too much into the weeds and perhaps we can use the solid/specification chat to continue the discussion and then propose changes here or make suggestions that can generally capture the related material.