architecture

(TODO)

URL structure

                        SIDEBAR                 PANE1                                                     PANE2

https://conze.pt/explore /Peyron ?l=en &t=wikipedia &i=21492627 &u=https://... &c=foo,bar,baz &t2=wikipedia i2=21492628 &u2=https://.. &c2=foo

              /<service>/<query>  ?l=<language> &t=<type>    &i=<index>  &u=<uri>        &c=<custom-data  &t2=<type-mode> i2=<index>  &u2=<uri>       &c2=<type-mode-custom-data>

core parameters:

<query> (used for the sidebar results)
  STRING: literal-query: (any string not beginning with a "?" character)
  default: ''

<l> (global active language)
  STRING: 2 or 3 letter iso-language-code
  default: 'en'

<t> | <t2>
  STRING: action-type
  default: 'wikipedia'

<i> | <i2>
  STRING: wikidata "Q identifier"
  default: ''

<u> | <u2>
  SERIALIZED URI STRING: to pass a URI
  default: ''

<c> | <c2>
  SERIALIZED OBJECT: to pass any custom data structure
  default: ''

other parameters:

<m>
  COMMA-SEPARATED-LIST of line marks (potential future use: referrals to any other conzept persistent indexes)
  default: ''

<d>
  BOOLEAN: direct-wikipedia-title toggle
  default: 'false' (note: only shown as parameter when set to 'true')

<s>
  BOOLEAN: sidebar visibility toggle
  default: 'true'

<v>
  SYMBOL: "desktop" or "mobile" view-mode request
  default: (depends on device type, but can be overruled)

wikipedia-qid?<h> (TODO)
  STRING: 2 or 3 letter iso-language-code of the i18n human-language interface
  default: 'en' (note: only shown as parameter when set)

app integration:

essential types:

wikipedia (requires a title)
wikipedia-qid (requires a Wikidata Qid)
link
link-split (only for p0)
url (not used for any pane, only for opening new tabs, TODO: prevent the useless URL updating)
articles (only for p0)
random (special case)

other types (mostly doing some external-content-control-complexity):

[ NOTE: push these into a mv-list OR into their own app if thats is possible! ]

wander (could this be turned into a 'link' type?)
dates, [m]
nearby ( → place into a mv-list? to research: detect if map is already being show, and then just send a postMessage)
map (cluster map with a deeper integration, move to a seperate “link” app?)

data

Conzept relies on using the JSON API's and semantic web technologies (SPARQL queries) to fetch its data. This data is heuristically classified (on the browser-client) into a self-created ontology of topic-classes (event, person, work, organization, organism, substance, …) and topic-subclasses (music, bird, …). This classification already covers more than 90% of all topics in Wikipedia (in all its languages) and is being improved all the time (both in quantity as well in quality / semantic-precision). The main challenge here is finding the right, usable topic-abstractions for the millions of topics. The live-rendering of the fetched data in the sidebar is configured using a JSON-field definition file, which allows processing various types of data (single values, arrays of values, booleans, SPARQL-query URLs) into an organized topic card. So the developer can add fields to the card by adding fields in that JSON file. These fields are parsed during 3-stages (creation, post-creation, rendering) and allow for code-triggers and field-depency checks. This allows eg. to only show some card-sections like the science→biology section if that is relevant. This topic-card rendering is also what sets Conzept apart from some other Wikidata rendering tools, in that it allows for a more complex layout (many topics in the sidebar with infinite-paging functionality and a tree-hierarchy of sections to only reveal what the user wants to see), user interactivity (inline lists of SPARQL data, etc.) and better performance (only when a button is clicked, will the required data be fetched).

architecture

Conzept is a Single Page Application (SPA) build upon: JavaScript, HTML, CSS, various JS libraries (including jQuery), various JSON data files and a large set of (iframe-embeddable) self-hosted web-apps. This microservice-oriented architecture improves the development agility, becasue existing/future semantic apps can easily be integrated into Conzept with a clean separation of concerns. So eg. there is a separate web-app for rendering Wikipedia articles and another for showing YouTube videos. There are about 40 of such self-hosted web-apps. Some made by myself, and some made by others (and patched for better a integration). For most of the external apps I've been opensourcing the patches in my github account (https://github.com/waldenn?tab=repositories). The integration with these apps is done via common URL-parameters (mainly: topic title, iso2-language and the Wikidata Qid) and postMessage() iframe communication. This allows clicks in the embedded iframe to update views in other panes. This latter part was one of the trickier parts to get right and make simple, as there are many combinations of actions possible (which pane to update, what to show in that pane, etc.). All this now works across both desktop and mobile browsers. On mobile the layout is slightly-different from the desktop view, since each pane on mobile takes up the whole screen and the user can swipe between these screens. In addition to those embedded apps there are also inline-views of content in the sidebar. An example of this is the dynamic viewing of the category-tree for topics that have a category. Other examples are SPARQL-query results displayed as inline lists or as dynamicaly inserted maps of locations or a table of results from a SPARQL-query. Example of the latter: https://twitter.com/conzept__/status/1398782565855731713