Splitting the work - Revision history

Podehaye: /* Conclusions */

2019-05-20T09:56:03Z

Conclusions

Podehaye: /* Conclusions */

2019-05-20T09:51:56Z

Conclusions

Podehaye: /* Formatting */

2019-05-20T09:49:30Z

Formatting

Podehaye: /* Formatting */

2019-05-20T09:48:32Z

Formatting

192.168.0.1: /* Formatting */

2019-05-20T09:47:49Z

Formatting

192.168.0.1: /* Semantics */

2019-05-20T09:46:47Z

Semantics

Podehaye at 08:25, 20 May 2019

2019-05-20T08:25:18Z

Podehaye: /* Lessons from "telephone number" */

2019-05-20T08:24:00Z

Lessons from "telephone number"

192.168.0.1 at 08:10, 20 May 2019

2019-05-20T08:10:08Z

192.168.0.1 at 13:45, 26 April 2019

2019-04-26T13:45:53Z

← Older revision		Revision as of 09:56, 20 May 2019
Line 49:		Line 49:
	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 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.	+	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.

← Older revision		Revision as of 09:51, 20 May 2019
Line 47:		Line 47:

	== Conclusions ==		== 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.

@@ Line 44: / Line 44: @@
 == 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.
+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 ==

@@ Line 44: / Line 44: @@
 == Formatting ==
-There is also the question of formatting. What constitutes a properly stored phone number? We didn't touch that yet.
+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.
 == Conclusions ==

@@ Line 44: / Line 44: @@
 == Formatting ==
+There is also the question of formatting. What constitutes a properly stored phone number? We didn't touch that yet.
-=== Conclusions ===
+== Conclusions ==

@@ Line 41: / Line 41: @@
 == 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.
+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 ==

@@ Line 1: / Line 1: @@
 There are many options for storing data and code in the Wikibase system:
 * as data entering the item/property paradigm;
@@ Line 19: / Line 20: @@
 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" ==
+= 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 ===
+== Computing ==
 The server computing environment could be:
 * gadgets;
@@ Line 36: / Line 37: @@
 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 ===
+== 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 ===
+== 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.
 === Conclusions ===
+*

← Older revision		Revision as of 08:24, 20 May 2019
Line 20:		Line 20:

	== Lessons from "telephone number" ==		== 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.
		+
		+	=== Conclusions ===
		+	*

← Older revision		Revision as of 08:10, 20 May 2019
Line 18:		Line 18:

	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" ==

← Older revision		Revision as of 13:45, 26 April 2019
Line 16:		Line 16:

	A concrete example can illustrate the last two points: the system might want to store in the user's personal data store that the "_ga" cookie on the website "example.com" had a given value. Alongside, the system should also store, that the email address of the user is "joe@schmo.com". Both are attributes of the individual user, so they should be stored in the same way. The best way to achieve this is to have one item for "email address", and one for "_ga cookie on example.com". We call this principle "internet architecture as semantic data": what is at the level of ecosystem architecture is what is not personal data, and should follow semantic principles. In this way individual level data can be clearly identified and manipulated, in a privacy preserving way.		A concrete example can illustrate the last two points: the system might want to store in the user's personal data store that the "_ga" cookie on the website "example.com" had a given value. Alongside, the system should also store, that the email address of the user is "joe@schmo.com". Both are attributes of the individual user, so they should be stored in the same way. The best way to achieve this is to have one item for "email address", and one for "_ga cookie on example.com". We call this principle "internet architecture as semantic data": what is at the level of ecosystem architecture is what is not personal data, and should follow semantic principles. In this way individual level data can be clearly identified and manipulated, in a privacy preserving way.
		+
		+	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.