15,627
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + Line 19:
Line 20: − == Lessons from "telephone number" ==+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→Conclusions
= Overview =
There are many options for storing data and code in the Wikibase system:
There are many options for storing data and code in the Wikibase system:
* as data entering the item/property paradigm;
* as data entering the item/property paradigm;
In general, the code base, distributed over many different languages and modes of operation, should be seen as a toolkit enabling others to craft their own experiments.
In general, the code base, distributed over many different languages and modes of operation, should be seen as a toolkit enabling others to craft their own experiments.
= Lessons from "telephone number" =
We implemented a quick system for storing {{Q|488}} locally and interfacing with the server.
The perspective/goal has been refined: smooth distribution of data and computation across server and client.
== Computing ==
The server computing environment could be:
* gadgets;
* user scripts;
* other?
The client computing environment could be:
* the browser javascript environment,
* a browser extension (in [https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Anatomy_of_a_WebExtension background page or content scripts])
The client itself can distribute its data however it pleases, as well as the computations it needs to perform. The server serves code that has to be run.
== Static data ==
For static data, we win the closest we are to storing RDF graphs. RDF graphs (i.e. collections of triples) have the advantage that they are directly interoperable at a technical level. Just append the two files. So when we store data, including in the browser, etc, we should be as close to that as possible.
== Semantics ==
Beyond mere storage of data, the semantics matter as well. For interoperability reasons (multiple servers eventually), it makes sense to get as far away from possible from the intricacies of Wikibase, and refer to concepts using external tags, possibly coming from well-known ontologies. This is true on server side, as well as on client side (when data is stored in browser storage, for instance).
== Formatting ==
There is also the question of formatting. What constitutes a properly stored phone number? We didn't touch that yet, but presumably it could be stored also by an additional server, possibly separate from the server holding the ontology. (Actually, we did, to deal with the mess of Wikibase properties and qualifiers, but this is "one level higher" in the abstraction, not looking at values of user attributes, but how properties and items are indexed in our instance)
== Conclusions ==
For static data we need to keep as close as possible to RDF format, everywhere. rdflib.js and the concept of "named graphs" can help.
For computation (code), we need to decouple as much as possible prototype definitions, instantiation of the objects, and the definitions of static storage of properties and methods. In JavaScript, 'this' is our friend, as it allows us to attach fluidly code to data. But it will only remain our friend if we are deliberate in what we are doing.