- From: Aaron Gray <aaronngray@gmail.com>
- Date: Mon, 6 Mar 2023 17:55:19 +0000
- To: Johannes Ernst <johannes.ernst@gmail.com>
- Cc: Bob Wyman <bob@wyman.us>, Benjamin Goering <ben@bengo.co>, public-swicg@w3.org
- Message-ID: <CAKXmGHAsLxwxAS2Z2e+kY6kZYfyX7Ki2fA5ywVF4m=E6BHcuJA@mail.gmail.com>
On Mon, 6 Mar 2023 at 17:49, Johannes Ernst <johannes.ernst@gmail.com> wrote: > On Mar 6, 2023, at 07:55, Aaron Gray <aaronngray@gmail.com> wrote: > > As I say this is only a problem if you are programming on an instance > level with hand coded code. If you work at a meta level then all you need > is for clients to provide their @context properly and provide an @context > on fingering or in /.well-known/ then this is not an issue for meta level > systems. Most protocol extensions can be automated even at the UI end of > the problem or prompt for meta-admin assistance to appropriate mappings. > > > I’m not understanding what you mean by “meta level systems”. Do you mean > software that can process any extension because it essentially extends its > type system when it encounters new stuff? (e.g. by downloading new @context > resources etc) > If so, then sure, but it only helps on the lower levels of the application > stack, like with networking and storage. It does not help you towards > creating a good, (consumer-grade, not geek-grade) UI, which almost > certainly requires “hand coded” elements, otherwise all you get is the > equivalent of property sheets. How should it know that extension should > offer to take a photo, while the other should offer to insert GPS data — to > pick some random examples? > Using an semantic stack with RDF and OWL, then JSON storage using something like JSON fields in PostgeSQL, MongoDB, or other NoSQL DB. Then using a meta forms approach to the UI it can all be done. For efficiency the stack can be compiled down and lowered to instance code. This is what I am working towards anyway.
Received on Monday, 6 March 2023 17:55:42 UTC