Property:Contains text
- Text
- schema:text (schema | Schema.org, V 14.0)
C
[[Page Schemas#Creating a new Schema]]
Page schemas is mostly a handy way to generate boilerplate templates and link them to semantic properties. A Form (using [[Page Forms]] is something that is an interface for filling in values for a template.
For an example of how this shakes out, see
[[:Category:Participant]]
[[Template:Participant]]
[[Form:Participant]]
* go to a `Category:CategoryName` page, creating it if it doesn't already exist.
* Click "Create schema" in top right
* If you want a form, check the "Form" box. it is possible to make a schema without a form. The schema just defines what pages will be generated, and the generated pages can be further edited afterwards (note that this might make them inconsistent with the schema)
* Click "add template" If you are only planning on having one template per category, name the template the same thing as the category.
* Add fields! Each field can have a corresponding form input (with a type, eg. a textbox, token input, date selector, etc.) and a semantic property.
* Once you're finished, save the schema
* Click "Generate pages" on the category page. Typically you want to uncheck any pages that are already bluelinks so you don't overwrite them. You might have to do the 'generate pages' step a few times, and it can take a few minutes, bc it's pretty buggy. +
Konrad, are you familiar with [[Chemical Markup Language]] (CML)? I stumbled across it on Twitter a few weeks ago via discussions about open publishing, and was surprised at the longevity of the project. I don’t love XML, but it seems to have gained some traction in its day, though I am not sure how active it is these days. https://en.m.wikipedia.org/wiki/Chemical_Markup_Language +
[[Page Schemas#Creating a new Schema]]
Page schemas is mostly a handy way to generate boilerplate templates and link them to semantic properties. A Form (using [[Page Forms]] is something that is an interface for filling in values for a template.
For an example of how this shakes out, see
[[:Category:Participant]]
[[Template:Participant]]
[[Form:Participant]]
* go to a `Category:CategoryName` page, creating it if it doesn't already exist.
* Click "Create schema" in top right
* If you want a form, check the "Form" box. it is possible to make a schema without a form. The schema just defines what pages will be generated, and the generated pages can be further edited afterwards (note that this might make them inconsistent with the schema)
* Click "add template" If you are only planning on having one template per category, name the template the same thing as the category.
* Add fields! Each field can have a corresponding form input (with a type, eg. a textbox, token input, date selector, etc.) and a semantic property.
* Once you're finished, save the schema
* Click "Generate pages" on the category page. Typically you want to uncheck any pages that are already bluelinks so you don't overwrite them. You might have to do the 'generate pages' step a few times, and it can take a few minutes, bc it's pretty buggy. +
[[claim]] claims and questions dominate in natural conversation; the imbalance of sources & evidence is quite stark. This aligns with my mental model of *conversational charity*, where we assume our interlocutors *could* ground their statements in evidence if pressed, but skip this step in the interest of time. +
i agree it's not universal! my feeling is that [[Claim]]: a statement (claim or evidence) might be the more universal element:
- empirical work also consists of statements about the world (this is less controversial)
- design/technological innovation rests in part on claims about a) what is needed in the world, what is hard to do, constraints, and b) what is needed to succeed: examples here: https://deepscienceventures.com/content/the-outcomes-graph-2 (h/t <@559775193242009610>)
- theories often consist of systems of core claims (e.g., in models like what <@824740026575355906> and <@734802666441408532> are working with, where we can think of the claims as subgraphs of the overall knowledge graph)
see, e.g., [[Evidence]] from this review of models of scientific knowledge https://publish.obsidian.md/joelchan-notes/discourse-graph/evidence/EVD+-+Four+positivist+epistemological+models+from+philosophy+of+science%2C+including+Popper%2C+emphasiz...+statements+as+a+core+component+of+scientific+knowledge+-+%40harsDesigningScientificKnowledge2001
and [[Evidence]] convergence/contrasts across users of the [[Roam Discourse Graph extension]] in terms of building blocks: common thread across all was Evidence +
my examples are more the latter.
there are also strong roots in this idea of [[Infrastructure]] in CSCW, studying lots of attempts to get scientists to adopt new infrastructure and why they... didn't work.
one challenge is the [[Claim]] that "infrastructures often fail because of the inertia of the installed base" (existing software, workflows, norms, institutions, legal codes, etc.)
one decent entry point [[Source]] on this:
Information Infrastructures and the Challenge of the Installed Base +
To add to the [[Reading List#Linked Data]] on [[Linked Data]], [[Standards]], and [[Collaboration]]: a piece from one of the authors of [[ActivityPub]] on the merger of the distributed messaging and linked data communities that I think puts into context what a massive achievement AP was
http://dustycloud.org/blog/on-standards-divisions-collaboration/ +
encouraging the use of the thread for the sake of people's notifications as we enter slow-mode.
sidebar: this to me is one of the more interesting uses of this kind of wiki-bot, in a more long-lived chat and communication medium (glad 2 have <@708787219992805407> here for the long-timescales perspective btw). in both this and any future workshops, being able to plug in something like a wikibot that can let different threads get tagged to common concepts through time to different/overlapping discord servers and output to potentially multiple overlapping wikis is v interesting to me.
I'm gonna continue to make it easier to deploy because i feel like the [[Garden and Stream]] metaphor is one that can unfold on multiple timescales, and it would be cool to build out the ability to make that easier: how cool would it be if you didn't have to decide on a chat/document medium or have to make a new set at the start of an organizing project since it was arbitrary anyway and your infra supported use and crossposting across many media.
Eg. the very understanding surfacing of [[The Google Docs Problem]] because of [[Mediawiki]]'s lack of [[Synchronous Editing]] [[Live Editing]] and the need to remember to link out to external services rather than that being a natural expectation of a multimodal group and having systems that explicitly support that is illustrative to me. Maybe one description is being able to deploy a [[Context of Interoperability]] [[Interoperability]]: during this time period I am intending these documents/discord servers/hashtags/social media accounts/etc. to be able to crosspost between each other so that everyone needs to to as little as possible to make their workflows align +
in thinking about some of the problems from this weekend like the (affectionately titled) [[The Google Docs Problem]] and various other interface problems with the wiki, where it'll always be easier for people to interact with a system from something they're more used to using, I've been thinking about a more generalized kind of bridging where one can set a [[Context of Interoperability]] where for a given workshop, time period, project, etc. people can plug their tools together and work in a shared space without needing to make all of them anew - so for the simple example of this discord and this wiki, it should be possible to reuse this space to eg. connect to a different (or multiple) wikis, and vice versa to have a different discord connect to it. Along those lines, being able to have a synchronizing eg. git repository of the pages on the wiki so that people could edit them in obsidian or logseq or whatever their tool of choice is... this feels like an incredibly generic idea, so I feel like there must already be a ton of work on it, but it feels like it starts by just making a framework for bridging where the n-to-n problem is simplified by having a set of tools for auth and format translation and modeling documents and messages... I'm going to start sketching one piece of that with the [[Mediawiki-Git Bridge]], but I'm curious to hear if anyone either has any ideas, prior experience, or unmet needs that I might be orbiting around here +
D
check this out. [[DIY Algorithms]]. instead of adding accounts to lists and autopopulating, you can directly add posts themselves. so then you can rig up whatever the frick algorithm you want to masto:
https://social.coop/@jonny/109545449455062668
https://github.com/sneakers-the-rat/mastodon/tree/feature/postlists +
[[Page Schemas#Creating a new Schema]]
Page schemas is mostly a handy way to generate boilerplate templates and link them to semantic properties. A Form (using [[Page Forms]] is something that is an interface for filling in values for a template.
For an example of how this shakes out, see
[[:Category:Participant]]
[[Template:Participant]]
[[Form:Participant]]
* go to a `Category:CategoryName` page, creating it if it doesn't already exist.
* Click "Create schema" in top right
* If you want a form, check the "Form" box. it is possible to make a schema without a form. The schema just defines what pages will be generated, and the generated pages can be further edited afterwards (note that this might make them inconsistent with the schema)
* Click "add template" If you are only planning on having one template per category, name the template the same thing as the category.
* Add fields! Each field can have a corresponding form input (with a type, eg. a textbox, token input, date selector, etc.) and a semantic property.
* Once you're finished, save the schema
* Click "Generate pages" on the category page. Typically you want to uncheck any pages that are already bluelinks so you don't overwrite them. You might have to do the 'generate pages' step a few times, and it can take a few minutes, bc it's pretty buggy. +
[[Page Schemas#Creating a new Schema]]
Page schemas is mostly a handy way to generate boilerplate templates and link them to semantic properties. A Form (using [[Page Forms]] is something that is an interface for filling in values for a template.
For an example of how this shakes out, see
[[:Category:Participant]]
[[Template:Participant]]
[[Form:Participant]]
* go to a `Category:CategoryName` page, creating it if it doesn't already exist.
* Click "Create schema" in top right
* If you want a form, check the "Form" box. it is possible to make a schema without a form. The schema just defines what pages will be generated, and the generated pages can be further edited afterwards (note that this might make them inconsistent with the schema)
* Click "add template" If you are only planning on having one template per category, name the template the same thing as the category.
* Add fields! Each field can have a corresponding form input (with a type, eg. a textbox, token input, date selector, etc.) and a semantic property.
* Once you're finished, save the schema
* Click "Generate pages" on the category page. Typically you want to uncheck any pages that are already bluelinks so you don't overwrite them. You might have to do the 'generate pages' step a few times, and it can take a few minutes, bc it's pretty buggy. +
[[joel chan]] -> [[decentralized discourse graph]] +
[[Page Schemas#Creating a new Schema]]
Page schemas is mostly a handy way to generate boilerplate templates and link them to semantic properties. A Form (using [[Page Forms]] is something that is an interface for filling in values for a template.
For an example of how this shakes out, see
[[:Category:Participant]]
[[Template:Participant]]
[[Form:Participant]]
* go to a `Category:CategoryName` page, creating it if it doesn't already exist.
* Click "Create schema" in top right
* If you want a form, check the "Form" box. it is possible to make a schema without a form. The schema just defines what pages will be generated, and the generated pages can be further edited afterwards (note that this might make them inconsistent with the schema)
* Click "add template" If you are only planning on having one template per category, name the template the same thing as the category.
* Add fields! Each field can have a corresponding form input (with a type, eg. a textbox, token input, date selector, etc.) and a semantic property.
* Once you're finished, save the schema
* Click "Generate pages" on the category page. Typically you want to uncheck any pages that are already bluelinks so you don't overwrite them. You might have to do the 'generate pages' step a few times, and it can take a few minutes, bc it's pretty buggy. +
That said, the more abstract idea of defining a data model plus execution semantics that any programming language can plug into looks very promising. That aspect of WikiLambda was in fact one of my inspirations for developing [[Digital Scientific Notations]]. +
[[joel chan]] -> [[decentralized discourse graph]] +
thank you! [[meta]] why zoom instead of something like [[jitsi]] +
apologies I didn't make it to [[discourse modeling]]! +
Nice idea, that [[Wikibot]]! Do I understand correctly that it grabs all messages that contain a page name in double brackets, and adds them to the Wiki page with that name? (this message being as much a test as a question of course) +
Looking forward to your work in this space! I do know about [[Fedwiki]] but only as a spectator. I tried to convince a few colleagues to set up a network of Fedwikis in our research domain, but nobody was keen on becoming a sysadmin to run their own Wiki instance. +