Doctorado

	url = {http://people.untyped.org/damien.pollet/software/citezen/},
	urldate = {2014-10-12},
	author = {Pollet, Damien},
	note = {00000}
}

@incollection{sharp_chapter_1997,
	address = {New York},
	title = {Chapter 12. {Strings}},
	isbn = {0-07-913036-4},
	shorttitle = {sbe-strings},
	url = {http://stephane.ducasse.free.fr/FreeBooks/ByExample/14%20-%20Chapter%2012%20-%20Strings.pdf},
	booktitle = {Smalltalk by {Example}: the {Developer}'s {Guide}},
	publisher = {McGraw Hill},
	author = {Sharp, Alex},
	year = {1997},
	note = {00000}
}

@techreport{pollet_citezen_2009,
	title = {Citezen, a nicer bibliography toolkit},

	url = {http://mutabit.com/repos.fossil/piamed/doc/tip/linea-base-aras-iecas.html},
	urldate = {2018-04-17},
	author = {Gil Rojas, Yanneth and Luna Cárdenas, Offray Vladimir},
	month = aug,
	year = {2014}
}










@misc{granger_jupyterlab:_2016,
	title = {{JupyterLab}: {Building} {Blocks} for {Interactive} {Computing} {\textbar} {SciPy} 2016},
	shorttitle = {{JupyterLab}},
	url = {https://www.youtube.com/watch?v=Ejh0ftSjk6g},
	urldate = {2018-04-18},
	author = {Granger, Brian},
	year = {2016},

	title = {I {Don}'t {Like} {Notebooks} - {Joel} {Grus} - \#{JupyterCon} 2018},
	url = {https://docs.google.com/presentation/d/1n2RlMdmv1p25Xy5thJUhkKGvjtV-dkAIsUXP-AL4ffI},
	urldate = {2018-10-29},
	author = {Grus, Joel},
	month = aug,
	year = {2018}
}

@book{sharp_smalltalk_1997,
	address = {New York},
	title = {Smalltalk by example: the developer's guide},
	isbn = {978-0-07-913036-5},
	shorttitle = {Smalltalk by example},
	publisher = {McGraw Hill},
	author = {Sharp, Alec},
	year = {1997},
	keywords = {Smalltalk (Computer program language), VisualWorks}
}

@misc{luna_cardenas_grafoscopio:_2015,
	title = {Grafoscopio: {Iceberg} metaphor for writing and data visualization},
	shorttitle = {Grafoscopio},
	url = {http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html},
	abstract = {This post describes a project I have been working on in Smalltalk as an alternative way to
approach open/garage/citizen science \& research by bulding a tool for "deep" / emergent data
narratives and v},
	language = {es},
	urldate = {2018-10-30},
	journal = {Palimpsesto, hipertexto, destripa/atrapa musas},
	author = {Luna Cárdenas, Offray Vladimir},
	month = jan,
	year = {2015}
}

@article{colquhoun_publish-or-perish:_2011,
	chapter = {Science},
	title = {Publish-or-perish: {Peer} review and the corruption of science {\textbar} {David} {Colquhoun}},
	issn = {0261-3077},
	shorttitle = {Publish-or-perish},
	url = {https://www.theguardian.com/science/2011/sep/05/publish-perish-peer-review-science},
	abstract = {David Colquhoun: Pressure on scientists to publish has led to a situation where any paper, however bad, can now be printed in a journal that claims to be peer-reviewed},
	language = {en-GB},
	urldate = {2018-10-30},
	journal = {The Guardian},
	author = {Colquhoun, David},
	month = sep,
	year = {2011},
	keywords = {Alternative medicine, Controversies, Education, Health, Higher education, Medical research, Peer review and scientific publishing, Science, Science and scepticism, Society}
}

@book{santos_end_2018,
	address = {Durham},
	title = {The end of the cognitive empire: the coming of age of epistemologies of the {South}},
	isbn = {978-1-4780-0000-6 978-1-4780-0015-0},
	shorttitle = {The end of the cognitive empire},
	publisher = {Duke University Press},
	author = {Santos, Boaventura de Sousa},
	year = {2018},
	keywords = {Developing countries, Knowledge, Sociology of, Social epistemology, Social justice}
}

suficientemente intensivas para avanzar el el problema.
Una particularidad acá fue el cambio del problema, para adecuarlo a las necesidades percibidas 
en la investigación Ciudad de Datos, según uno de los coinvestigadores.
Esto trajo la ventaja de triangular información: ya no estábamos más centrados en los temas de 
redes sociales, sino que podíamos poner a circular en ellas información extraida de otros lados, 
en este caso del portal de contratación pública, en aras de articularnos con la naciente comunidad 
\emph{Open Data Colombia} (OpenDataCo) y el \emph{scrapper} de contratos del portal 
gubernamental colombiano ``contratos.gov.co''. % (prizbilla-xxx)
Además nos alineaba con otras comunidades como OpenBugets\footnote{\url{http://openbudgets.eu/}}, 
OpenSpending\footnote{\url{https://openspending.org/}} y algunos proyectos y temáticas de la 
Open Knowledge Foundation\footnote{\url{https://discuss.okfn.org/}}.

\begin{figure}[htb]
	\includegraphics[width=\linewidth]{./Parte2/open-spending.png}%
	\caption[Gasto público]

final de este capítulo.
El encuentro mismo era una forma de participación que permanentemente construía cosificaciones sobre
los aprendizajes y la memoria que se estructuraban progresivamente.
La siguiente parte menciona las formas de cosificación creadas durante los Data Weeks y Data Rodas,
por los participantes, así como los canales de comunicación permanentes.
A los prototipos desarrollados, les damos su lugar particular en el capítulo \ref{prototipos}.

\section{Espacios virtuales: Pads, Fossil, Lista de correo, Telegram}\label{encuentro-digital}

El software social, en la definición de Tom A. Coates (\citeyear{coates_my_2003,coates_addendum_2005})
es aquel de propicia, extiende y deriva valor de las interacciones sociales.
Este ha sido divido en dos grupos\footnote{La taxonomía entre software social conversacional o dialógico
	la encontré en un wiki, cuyos contenidos no puedo recuperar nuevamente.
	Si mal no estoy se traba de \url{http://wiki.c2.com/}.
	Dicha taxonomía me ha sido útil para encontrar los énfasis en la interacción de un software

La documentación juega un papel activo a lo largo de las varias ediciones del Data Week.
Para ello se usan varios sistemas de documentación que permitían capturar lo emergente,
complementar el encuentro cara a cara, ser resilientes y minimalistas, de modo que era
posible para los asistentes de las últimas ediciones, llevarse una copia con la memoria
de todos los eventos desde el comienzo, con una infraestructura sencilla pero potente.

Se emplearon mayoritariamente etherpads\footnote{\url{http://etherpad.org/}}  y luego 
CodiMD\footnote{\url{https://demo.codimd.org/}}, que son sistemas de escritura colaborativa
de documentos textuales en tiempo real, llamados tambien \emph{pads} a los que se unen los 
participantes con sólo compartir un enlace web.
Dichos enlaces, que iniciaban el pad, se compartían empleando un acortador de direcciones
ético, que no rastrea a quienes lo emplean, disponible en \hyperlink{https://is.gd}{is.gd}.
Las memorias se fueron organizando de modo que el primer pad se usaba como una índice para 
los otros pads que guardaban la memoria cronológica o temática desarrollada durante cada una 
de las sesiones diarias que constituían el Data Week (o Data Roda).

Debido a la reubicación de algunos miembros de la comunidad a países europeos con otros
usos horarios, la documentación empezó a volverse más estructurada, para facilitar así
la participación remota.
Esto hizo que empezáramos a escribir los pads empleando el lenguaje de etiquetamiento
ligero Markdown, de modo que pudiéramos expresar tanto la estructura como la presentación
visual del documento a través de marcas sencillas (etiquetas).

-- Module options:
local always_try_using_lpeg = true
local register_global_module_table = false
local global_module_name = 'json'

--[==[

David Kolf's JSON module for Lua 5.1/5.2

Version 2.5


For the documentation see the corresponding readme.txt or visit
<http://dkolf.de/src/dkjson-lua.fsl/>.

You can contact the author by sending an e-mail to 'david' at the
domain 'dkolf.de'.


Copyright (C) 2010-2013 David Heiko Kolf

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

--]==]

-- global dependencies:
local pairs, type, tostring, tonumber, getmetatable, setmetatable, rawset =
      pairs, type, tostring, tonumber, getmetatable, setmetatable, rawset
local error, require, pcall, select = error, require, pcall, select
local floor, huge = math.floor, math.huge
local strrep, gsub, strsub, strbyte, strchar, strfind, strlen, strformat =
      string.rep, string.gsub, string.sub, string.byte, string.char,
      string.find, string.len, string.format
local strmatch = string.match
local concat = table.concat

local json = { version = "dkjson 2.5" }

if register_global_module_table then
  _G[global_module_name] = json
end

local _ENV = nil -- blocking globals in Lua 5.2

pcall (function()
  -- Enable access to blocked metatables.
  -- Don't worry, this module doesn't change anything in them.
  local debmeta = require "debug".getmetatable
  if debmeta then getmetatable = debmeta end
end)

json.null = setmetatable ({}, {
  __tojson = function () return "null" end
})

local function isarray (tbl)
  local max, n, arraylen = 0, 0, 0
  for k,v in pairs (tbl) do
    if k == 'n' and type(v) == 'number' then
      arraylen = v
      if v > max then
        max = v
      end
    else
      if type(k) ~= 'number' or k < 1 or floor(k) ~= k then
        return false
      end
      if k > max then
        max = k
      end
      n = n + 1
    end
  end
  if max > 10 and max > arraylen and max > n * 2 then
    return false -- don't create an array with too many holes
  end
  return true, max
end

local escapecodes = {
  ["\""] = "\\\"", ["\\"] = "\\\\", ["\b"] = "\\b", ["\f"] = "\\f",
  ["\n"] = "\\n",  ["\r"] = "\\r",  ["\t"] = "\\t"
}

local function escapeutf8 (uchar)
  local value = escapecodes[uchar]
  if value then
    return value
  end
  local a, b, c, d = strbyte (uchar, 1, 4)
  a, b, c, d = a or 0, b or 0, c or 0, d or 0
  if a <= 0x7f then
    value = a
  elseif 0xc0 <= a and a <= 0xdf and b >= 0x80 then
    value = (a - 0xc0) * 0x40 + b - 0x80
  elseif 0xe0 <= a and a <= 0xef and b >= 0x80 and c >= 0x80 then
    value = ((a - 0xe0) * 0x40 + b - 0x80) * 0x40 + c - 0x80
  elseif 0xf0 <= a and a <= 0xf7 and b >= 0x80 and c >= 0x80 and d >= 0x80 then
    value = (((a - 0xf0) * 0x40 + b - 0x80) * 0x40 + c - 0x80) * 0x40 + d - 0x80
  else
    return ""
  end
  if value <= 0xffff then
    return strformat ("\\u%.4x", value)
  elseif value <= 0x10ffff then
    -- encode as UTF-16 surrogate pair
    value = value - 0x10000
    local highsur, lowsur = 0xD800 + floor (value/0x400), 0xDC00 + (value % 0x400)
    return strformat ("\\u%.4x\\u%.4x", highsur, lowsur)
  else
    return ""
  end
end

local function fsub (str, pattern, repl)
  -- gsub always builds a new string in a buffer, even when no match
  -- exists. First using find should be more efficient when most strings
  -- don't contain the pattern.
  if strfind (str, pattern) then
    return gsub (str, pattern, repl)
  else
    return str
  end
end

local function quotestring (value)
  -- based on the regexp "escapable" in https://github.com/douglascrockford/JSON-js
  value = fsub (value, "[%z\1-\31\"\\\127]", escapeutf8)
  if strfind (value, "[\194\216\220\225\226\239]") then
    value = fsub (value, "\194[\128-\159\173]", escapeutf8)
    value = fsub (value, "\216[\128-\132]", escapeutf8)
    value = fsub (value, "\220\143", escapeutf8)
    value = fsub (value, "\225\158[\180\181]", escapeutf8)
    value = fsub (value, "\226\128[\140-\143\168-\175]", escapeutf8)
    value = fsub (value, "\226\129[\160-\175]", escapeutf8)
    value = fsub (value, "\239\187\191", escapeutf8)
    value = fsub (value, "\239\191[\176-\191]", escapeutf8)
  end
  return "\"" .. value .. "\""
end
json.quotestring = quotestring

local function replace(str, o, n)
  local i, j = strfind (str, o, 1, true)
  if i then
    return strsub(str, 1, i-1) .. n .. strsub(str, j+1, -1)
  else
    return str
  end
end

-- locale independent num2str and str2num functions
local decpoint, numfilter

local function updatedecpoint ()
  decpoint = strmatch(tostring(0.5), "([^05+])")
  -- build a filter that can be used to remove group separators
  numfilter = "[^0-9%-%+eE" .. gsub(decpoint, "[%^%$%(%)%%%.%[%]%*%+%-%?]", "%%%0") .. "]+"
end

updatedecpoint()

local function num2str (num)
  return replace(fsub(tostring(num), numfilter, ""), decpoint, ".")
end

local function str2num (str)
  local num = tonumber(replace(str, ".", decpoint))
  if not num then
    updatedecpoint()
    num = tonumber(replace(str, ".", decpoint))
  end
  return num
end

local function addnewline2 (level, buffer, buflen)
  buffer[buflen+1] = "\n"
  buffer[buflen+2] = strrep ("  ", level)
  buflen = buflen + 2
  return buflen
end

function json.addnewline (state)
  if state.indent then
    state.bufferlen = addnewline2 (state.level or 0,
                           state.buffer, state.bufferlen or #(state.buffer))
  end
end

local encode2 -- forward declaration

local function addpair (key, value, prev, indent, level, buffer, buflen, tables, globalorder, state)
  local kt = type (key)
  if kt ~= 'string' and kt ~= 'number' then
    return nil, "type '" .. kt .. "' is not supported as a key by JSON."
  end
  if prev then
    buflen = buflen + 1
    buffer[buflen] = ","
  end
  if indent then
    buflen = addnewline2 (level, buffer, buflen)
  end
  buffer[buflen+1] = quotestring (key)
  buffer[buflen+2] = ":"
  return encode2 (value, indent, level, buffer, buflen + 2, tables, globalorder, state)
end

local function appendcustom(res, buffer, state)
  local buflen = state.bufferlen
  if type (res) == 'string' then
    buflen = buflen + 1
    buffer[buflen] = res
  end
  return buflen
end

local function exception(reason, value, state, buffer, buflen, defaultmessage)
  defaultmessage = defaultmessage or reason
  local handler = state.exception
  if not handler then
    return nil, defaultmessage
  else
    state.bufferlen = buflen
    local ret, msg = handler (reason, value, state, defaultmessage)
    if not ret then return nil, msg or defaultmessage end
    return appendcustom(ret, buffer, state)
  end
end

function json.encodeexception(reason, value, state, defaultmessage)
  return quotestring("<" .. defaultmessage .. ">")
end

encode2 = function (value, indent, level, buffer, buflen, tables, globalorder, state)
  local valtype = type (value)
  local valmeta = getmetatable (value)
  valmeta = type (valmeta) == 'table' and valmeta -- only tables
  local valtojson = valmeta and valmeta.__tojson
  if valtojson then
    if tables[value] then
      return exception('reference cycle', value, state, buffer, buflen)
    end
    tables[value] = true
    state.bufferlen = buflen
    local ret, msg = valtojson (value, state)
    if not ret then return exception('custom encoder failed', value, state, buffer, buflen, msg) end
    tables[value] = nil
    buflen = appendcustom(ret, buffer, state)
  elseif value == nil then
    buflen = buflen + 1
    buffer[buflen] = "null"
  elseif valtype == 'number' then
    local s
    if value ~= value or value >= huge or -value >= huge then
      -- This is the behaviour of the original JSON implementation.
      s = "null"
    else
      s = num2str (value)
    end
    buflen = buflen + 1
    buffer[buflen] = s
  elseif valtype == 'boolean' then
    buflen = buflen + 1
    buffer[buflen] = value and "true" or "false"
  elseif valtype == 'string' then
    buflen = buflen + 1
    buffer[buflen] = quotestring (value)
  elseif valtype == 'table' then
    if tables[value] then
      return exception('reference cycle', value, state, buffer, buflen)
    end
    tables[value] = true
    level = level + 1
    local isa, n = isarray (value)
    if n == 0 and valmeta and valmeta.__jsontype == 'object' then
      isa = false
    end
    local msg
    if isa then -- JSON array
      buflen = buflen + 1
      buffer[buflen] = "["
      for i = 1, n do
        buflen, msg = encode2 (value[i], indent, level, buffer, buflen, tables, globalorder, state)
        if not buflen then return nil, msg end
        if i < n then
          buflen = buflen + 1
          buffer[buflen] = ","
        end
      end
      buflen = buflen + 1
      buffer[buflen] = "]"
    else -- JSON object
      local prev = false
      buflen = buflen + 1
      buffer[buflen] = "{"
      local order = valmeta and valmeta.__jsonorder or globalorder
      if order then
        local used = {}
        n = #order
        for i = 1, n do
          local k = order[i]
          local v = value[k]
          if v then
            used[k] = true
            buflen, msg = addpair (k, v, prev, indent, level, buffer, buflen, tables, globalorder, state)
            prev = true -- add a seperator before the next element
          end
        end
        for k,v in pairs (value) do
          if not used[k] then
            buflen, msg = addpair (k, v, prev, indent, level, buffer, buflen, tables, globalorder, state)
            if not buflen then return nil, msg end
            prev = true -- add a seperator before the next element
          end
        end
      else -- unordered
        for k,v in pairs (value) do
          buflen, msg = addpair (k, v, prev, indent, level, buffer, buflen, tables, globalorder, state)
          if not buflen then return nil, msg end
          prev = true -- add a seperator before the next element
        end
      end
      if indent then
        buflen = addnewline2 (level - 1, buffer, buflen)
      end
      buflen = buflen + 1
      buffer[buflen] = "}"
    end
    tables[value] = nil
  else
    return exception ('unsupported type', value, state, buffer, buflen,
      "type '" .. valtype .. "' is not supported by JSON.")
  end
  return buflen
end

function json.encode (value, state)
  state = state or {}
  local oldbuffer = state.buffer
  local buffer = oldbuffer or {}
  state.buffer = buffer
  updatedecpoint()
  local ret, msg = encode2 (value, state.indent, state.level or 0,
                   buffer, state.bufferlen or 0, state.tables or {}, state.keyorder, state)
  if not ret then
    error (msg, 2)
  elseif oldbuffer == buffer then
    state.bufferlen = ret
    return true
  else
    state.bufferlen = nil
    state.buffer = nil
    return concat (buffer)
  end
end

local function loc (str, where)
  local line, pos, linepos = 1, 1, 0
  while true do
    pos = strfind (str, "\n", pos, true)
    if pos and pos < where then
      line = line + 1
      linepos = pos
      pos = pos + 1
    else
      break
    end
  end
  return "line " .. line .. ", column " .. (where - linepos)
end

local function unterminated (str, what, where)
  return nil, strlen (str) + 1, "unterminated " .. what .. " at " .. loc (str, where)
end

local function scanwhite (str, pos)
  while true do
    pos = strfind (str, "%S", pos)
    if not pos then return nil end
    local sub2 = strsub (str, pos, pos + 1)
    if sub2 == "\239\187" and strsub (str, pos + 2, pos + 2) == "\191" then
      -- UTF-8 Byte Order Mark
      pos = pos + 3
    elseif sub2 == "//" then
      pos = strfind (str, "[\n\r]", pos + 2)
      if not pos then return nil end
    elseif sub2 == "/*" then
      pos = strfind (str, "*/", pos + 2)
      if not pos then return nil end
      pos = pos + 2
    else
      return pos
    end
  end
end

local escapechars = {
  ["\""] = "\"", ["\\"] = "\\", ["/"] = "/", ["b"] = "\b", ["f"] = "\f",
  ["n"] = "\n", ["r"] = "\r", ["t"] = "\t"
}

local function unichar (value)
  if value < 0 then
    return nil
  elseif value <= 0x007f then
    return strchar (value)
  elseif value <= 0x07ff then
    return strchar (0xc0 + floor(value/0x40),
                    0x80 + (floor(value) % 0x40))
  elseif value <= 0xffff then
    return strchar (0xe0 + floor(value/0x1000),
                    0x80 + (floor(value/0x40) % 0x40),
                    0x80 + (floor(value) % 0x40))
  elseif value <= 0x10ffff then
    return strchar (0xf0 + floor(value/0x40000),
                    0x80 + (floor(value/0x1000) % 0x40),
                    0x80 + (floor(value/0x40) % 0x40),
                    0x80 + (floor(value) % 0x40))
  else
    return nil
  end
end

local function scanstring (str, pos)
  local lastpos = pos + 1
  local buffer, n = {}, 0
  while true do
    local nextpos = strfind (str, "[\"\\]", lastpos)
    if not nextpos then
      return unterminated (str, "string", pos)
    end
    if nextpos > lastpos then
      n = n + 1
      buffer[n] = strsub (str, lastpos, nextpos - 1)
    end
    if strsub (str, nextpos, nextpos) == "\"" then
      lastpos = nextpos + 1
      break
    else
      local escchar = strsub (str, nextpos + 1, nextpos + 1)
      local value
      if escchar == "u" then
        value = tonumber (strsub (str, nextpos + 2, nextpos + 5), 16)
        if value then
          local value2
          if 0xD800 <= value and value <= 0xDBff then
            -- we have the high surrogate of UTF-16. Check if there is a
            -- low surrogate escaped nearby to combine them.
            if strsub (str, nextpos + 6, nextpos + 7) == "\\u" then
              value2 = tonumber (strsub (str, nextpos + 8, nextpos + 11), 16)
              if value2 and 0xDC00 <= value2 and value2 <= 0xDFFF then
                value = (value - 0xD800)  * 0x400 + (value2 - 0xDC00) + 0x10000
              else
                value2 = nil -- in case it was out of range for a low surrogate
              end
            end
          end
          value = value and unichar (value)
          if value then
            if value2 then
              lastpos = nextpos + 12
            else
              lastpos = nextpos + 6
            end
          end
        end
      end
      if not value then
        value = escapechars[escchar] or escchar
        lastpos = nextpos + 2
      end
      n = n + 1
      buffer[n] = value
    end
  end
  if n == 1 then
    return buffer[1], lastpos
  elseif n > 1 then
    return concat (buffer), lastpos
  else
    return "", lastpos
  end
end

local scanvalue -- forward declaration

local function scantable (what, closechar, str, startpos, nullval, objectmeta, arraymeta)
  local len = strlen (str)
  local tbl, n = {}, 0
  local pos = startpos + 1
  if what == 'object' then
    setmetatable (tbl, objectmeta)
  else
    setmetatable (tbl, arraymeta)
  end
  while true do
    pos = scanwhite (str, pos)
    if not pos then return unterminated (str, what, startpos) end
    local char = strsub (str, pos, pos)
    if char == closechar then
      return tbl, pos + 1
    end
    local val1, err
    val1, pos, err = scanvalue (str, pos, nullval, objectmeta, arraymeta)
    if err then return nil, pos, err end
    pos = scanwhite (str, pos)
    if not pos then return unterminated (str, what, startpos) end
    char = strsub (str, pos, pos)
    if char == ":" then
      if val1 == nil then
        return nil, pos, "cannot use nil as table index (at " .. loc (str, pos) .. ")"
      end
      pos = scanwhite (str, pos + 1)
      if not pos then return unterminated (str, what, startpos) end
      local val2
      val2, pos, err = scanvalue (str, pos, nullval, objectmeta, arraymeta)
      if err then return nil, pos, err end
      tbl[val1] = val2
      pos = scanwhite (str, pos)
      if not pos then return unterminated (str, what, startpos) end
      char = strsub (str, pos, pos)
    else
      n = n + 1
      tbl[n] = val1
    end
    if char == "," then
      pos = pos + 1
    end
  end
end

scanvalue = function (str, pos, nullval, objectmeta, arraymeta)
  pos = pos or 1
  pos = scanwhite (str, pos)
  if not pos then
    return nil, strlen (str) + 1, "no valid JSON value (reached the end)"
  end
  local char = strsub (str, pos, pos)
  if char == "{" then
    return scantable ('object', "}", str, pos, nullval, objectmeta, arraymeta)
  elseif char == "[" then
    return scantable ('array', "]", str, pos, nullval, objectmeta, arraymeta)
  elseif char == "\"" then
    return scanstring (str, pos)
  else
    local pstart, pend = strfind (str, "^%-?[%d%.]+[eE]?[%+%-]?%d*", pos)
    if pstart then
      local number = str2num (strsub (str, pstart, pend))
      if number then
        return number, pend + 1
      end
    end
    pstart, pend = strfind (str, "^%a%w*", pos)
    if pstart then
      local name = strsub (str, pstart, pend)
      if name == "true" then
        return true, pend + 1
      elseif name == "false" then
        return false, pend + 1
      elseif name == "null" then
        return nullval, pend + 1
      end
    end
    return nil, pos, "no valid JSON value at " .. loc (str, pos)
  end
end

local function optionalmetatables(...)
  if select("#", ...) > 0 then
    return ...
  else
    return {__jsontype = 'object'}, {__jsontype = 'array'}
  end
end

function json.decode (str, pos, nullval, ...)
  local objectmeta, arraymeta = optionalmetatables(...)
  return scanvalue (str, pos, nullval, objectmeta, arraymeta)
end

function json.use_lpeg ()
  local g = require ("lpeg")

  if g.version() == "0.11" then
    error "due to a bug in LPeg 0.11, it cannot be used for JSON matching"
  end

  local pegmatch = g.match
  local P, S, R = g.P, g.S, g.R

  local function ErrorCall (str, pos, msg, state)
    if not state.msg then
      state.msg = msg .. " at " .. loc (str, pos)
      state.pos = pos
    end
    return false
  end

  local function Err (msg)
    return g.Cmt (g.Cc (msg) * g.Carg (2), ErrorCall)
  end

  local SingleLineComment = P"//" * (1 - S"\n\r")^0
  local MultiLineComment = P"/*" * (1 - P"*/")^0 * P"*/"
  local Space = (S" \n\r\t" + P"\239\187\191" + SingleLineComment + MultiLineComment)^0

  local PlainChar = 1 - S"\"\\\n\r"
  local EscapeSequence = (P"\\" * g.C (S"\"\\/bfnrt" + Err "unsupported escape sequence")) / escapechars
  local HexDigit = R("09", "af", "AF")
  local function UTF16Surrogate (match, pos, high, low)
    high, low = tonumber (high, 16), tonumber (low, 16)
    if 0xD800 <= high and high <= 0xDBff and 0xDC00 <= low and low <= 0xDFFF then
      return true, unichar ((high - 0xD800)  * 0x400 + (low - 0xDC00) + 0x10000)
    else
      return false
    end
  end
  local function UTF16BMP (hex)
    return unichar (tonumber (hex, 16))
  end
  local U16Sequence = (P"\\u" * g.C (HexDigit * HexDigit * HexDigit * HexDigit))
  local UnicodeEscape = g.Cmt (U16Sequence * U16Sequence, UTF16Surrogate) + U16Sequence/UTF16BMP
  local Char = UnicodeEscape + EscapeSequence + PlainChar
  local String = P"\"" * g.Cs (Char ^ 0) * (P"\"" + Err "unterminated string")
  local Integer = P"-"^(-1) * (P"0" + (R"19" * R"09"^0))
  local Fractal = P"." * R"09"^0
  local Exponent = (S"eE") * (S"+-")^(-1) * R"09"^1
  local Number = (Integer * Fractal^(-1) * Exponent^(-1))/str2num
  local Constant = P"true" * g.Cc (true) + P"false" * g.Cc (false) + P"null" * g.Carg (1)
  local SimpleValue = Number + String + Constant
  local ArrayContent, ObjectContent

  -- The functions parsearray and parseobject parse only a single value/pair
  -- at a time and store them directly to avoid hitting the LPeg limits.
  local function parsearray (str, pos, nullval, state)
    local obj, cont
    local npos
    local t, nt = {}, 0
    repeat
      obj, cont, npos = pegmatch (ArrayContent, str, pos, nullval, state)
      if not npos then break end
      pos = npos
      nt = nt + 1
      t[nt] = obj
    until cont == 'last'
    return pos, setmetatable (t, state.arraymeta)
  end

  local function parseobject (str, pos, nullval, state)
    local obj, key, cont
    local npos
    local t = {}
    repeat
      key, obj, cont, npos = pegmatch (ObjectContent, str, pos, nullval, state)
      if not npos then break end
      pos = npos
      t[key] = obj
    until cont == 'last'
    return pos, setmetatable (t, state.objectmeta)
  end

  local Array = P"[" * g.Cmt (g.Carg(1) * g.Carg(2), parsearray) * Space * (P"]" + Err "']' expected")
  local Object = P"{" * g.Cmt (g.Carg(1) * g.Carg(2), parseobject) * Space * (P"}" + Err "'}' expected")
  local Value = Space * (Array + Object + SimpleValue)
  local ExpectedValue = Value + Space * Err "value expected"
  ArrayContent = Value * Space * (P"," * g.Cc'cont' + g.Cc'last') * g.Cp()
  local Pair = g.Cg (Space * String * Space * (P":" + Err "colon expected") * ExpectedValue)
  ObjectContent = Pair * Space * (P"," * g.Cc'cont' + g.Cc'last') * g.Cp()
  local DecodeValue = ExpectedValue * g.Cp ()

  function json.decode (str, pos, nullval, ...)
    local state = {}
    state.objectmeta, state.arraymeta = optionalmetatables(...)
    local obj, retpos = pegmatch (DecodeValue, str, pos, nullval, state)
    if state.msg then
      return nil, state.pos, state.msg
    else
      return obj, retpos
    end
  end

  -- use this function only once:
  json.use_lpeg = function () return json end

  json.using_lpeg = true

  return json -- so you can get the module using json = require "dkjson".use_lpeg()
end

if always_try_using_lpeg then
  pcall (json.use_lpeg)
end

return json

	\\
	Mis estudiantes de la cohorte 11B de la Maestría en Didáctica de las
	Ciencias de la Fundación Universitaria Autónoma de Colombia leyeron,
	como una de las actividades de nuestro seminario de software libre y
	educación, borradores de este artículo e hicieron valiosos comentarios.
	}.
	
Grafoscopio es una herramienta amoldable para publicación e investigación reproducible y narrativas
y visualización ágiles de datos \cite{luna_cardenas_grafoscopio:_2017}, que permite mezclar prosa, código,
datos y gráficos. 
Realiza varios aportes, dentro del contexto indagar por la modificación recíproca 
entre comunidades y artefactos digitales, desde perspectivas críticas: es altamente cambiable, 
debido a estar realizado en el metasistema Pharo (un sistema hecho en sí mismo);
posee una metáfora uniforme para trabajar a lo largo del entorno (un enfoque objetual
puro), lo cual facilita su aprendizaje y modificación, contrastando con otros entornos que 
mezclan distintos paradigmas y tecnologías incrementando la complejidad incidental del problema
(aquella que no es esencial del mismo, sino producto de otras cosas, como las tecnologías con
las cuales se aborda -- \cite{luna_cardenas_grafoscopio:_2015});
tiene una perspectiva centrada en el Sur Global, desde la apuesta por lo que se llamó
``infraestructuras de bolsillo'' (sencillas, auto-contenidas y que funcionan bien en y fuera de
línea).
Al permitir narrativas computacionales e investigación y publicación reproducibles, realiza un 
puente entre el mundo impreso y el mundo computacional, pues al combinar prosa, código, texto, datos
y visualizaciones, con una fuerte apuesta por la llamada tecnología cívica, permite un ingreso de más 
saberes y sujetos, además de los habituales desarrolladores de software o los científicos de la computación.

Se mostrarán las ideas claves sobre los temas relacionados de esta tesis respecto
a la construcción de artefactos autorreferenciales, que complementan las dinámicas
autopoiéticas propias de las comunidades de práctica, y del desarrollo de
software como labor artesanal y desde actos de empoderamiento ciudadano.
Si bien Grafoscopio habita un ecosistema donde otras alternativas parecidas 
existen\footnote{El Manual de Usuario Grafoscopio (\emph{Grafoscopio User Manual},

%Ello permitirá la conexión con los dos capítulos siguientes, referidos a las
%dinámicas que se desarrollaron alrededor de Grafoscopio (Data Weeks, Data Rodas y
%otros encuentros), así como los otros artefactos digitales que se construyeron
%gracias a la interacción entre Grafoscopio y tales dinámicas.


\section{Investigaciones y ciencias otras, objetos de investigación reproducibles y activistas}\label{iccag-intro}


Como se apreció en los antecedentes, Grafoscopio tenía la intención de explorar
formas de escribir diferentes, que permitieran amplificar las voces de las comunidades
de base, usando maneras de argumentar desde los datos y las visualizaciones, en particular
en relación con las interacciones entre dichas comunidades y entidades estatales.
Ejemplos de ello se empezaron a avisorar en la Gobernatón y los prototipos de
\emph{Indie Web Science}, antes abordados.
Grafoscopio también tenía la intención de visibilizar los múltiples objetos 
de investigación, de los cuales la academia suele no dar cuenta, debido a las 
prácticas de validación de saberes que privilegian excesivamente lo escrito y la
publicación indexada\footnote{Un número creciente de
	académicos y posturas críticas se suman a esta lectura sobre el fetichismo y la mafia 
	de los artículos y la publicación indexada, desde artículos en periódicos, como 
	\emph{Publish-or-perish: Peer review and the corruption of science} (\cite{colquhoun_publish-or-perish:_2011}) 
	hasta blogs dedicados a estas posturas críticas, como \emph{Elephant in the room} 
	(\url{https://is.gd/elelab}) y libros, como \emph{The end of the cognitive empire: the coming of 
		age of epistemologies of the South} (\cite{santos_end_2018}),  que establecen otras epistemologías, narrativas, 
	objetos y formas de dar cuenta del conocimiento, que van más allá de lo la mayoría de instituciones y académicos, 
	con mirada positivista, reduccionista y/o extractivista reconocen como lo que es el conocimiento, sus sujetos 
	y sus objetos y los circuitos de publicación donde se mobilizan y visibilizan.}.

Como se vera en detalle más adelante, estas dos búsquedas tenían una intención común:
construir nuevas metáforas que a su vez permitiesen adquirir nuevos alfabetismos
sobre escritura, mediada por código, datos y visualización, lo que, a su vez, 
permitiera re y co-construir la metáfora original: \emph{cambiando así el artefacto que nos cambia}.
En ese sentido las elecciones hechas, por ejemplo, que el texto se presente como un árbol,
son temporales y puntos de partida para reconfigurar y desplegar dichas elecciones nuevamente.

	científicas.
\end{quote}

Una posibilidad similar hemos visto desde HackBo, cuando participamos desde
infraestructuras como Grafoscopio en debates sobre asuntos públicos o cuando
deconstruimos investigaciones de Big Data haciéndolas accesibles para muchos
(el capítulo \ref{prototipos} lo muestra en detalle).
Ahí estamos haciendo posible que el ciudadano participe del debate, rete al 
experto o muestre que esta no es una esfera siempre cerrada y que, por el 
contrario, puede incluir voces diversas.

Por su parte, \cite{lafuente_amateurs_2014} conecta a la ciencia ciudadana con
el movimiento hacker cuando dice que tal movimiento resistía la corporatización
del saber, pues era tan absurdo como privatizar las leyes de Newton o los teoremas
matemáticos y conecta este movimiento con otros movimientos e iniciativas, como
la Wikipedia, los Creative Commons, el movimiento punk y de hecho muestra una
perspectiva similar a la de Wark, Coleman o Schrock, antes vistas, cuando plurariza
el fenómeno hacker y lo conecta con diferentes sujetos y maneras de hacer conocimiento:



\begin{quote}
	La cultura hacker pronto resonó con la cultura punk. Ambas daban forma a
	los anhelos anticonsumistas, antimonopolistas y antielitistas. Ambas
	representaban una apuesta por la cultura del DIY, las formas
	cooperativas, las prácticas de garaje y la innovación maker. Hace ya
	cinco décadas que su presencia no deja de contagiar el mundo de los

	empresarial.
\end{quote}

Grafoscopio se relaciona críticamente con los movimientos de la ciencia de garage y ciudadana, 
pues precisamente ha ocurrido en el Hackerspace de Bogotá, HackBo, a propósito de dinámicas 
relacionadas con otras maneras de apropiar la tecnología y la ciencia y participar desde dicha 
apropiación de la vida social y pública.
Acá se piensa la investigación y ciencia ciudadana y de garage como aquellas que usa los métodos 
de las ciencias y la investigación para diversificar las voces que participan en ellas, y que se preocupa, 
particularmente, por la reproductibilidad, verificabilidad y construcción sobre lo dicho, incluso más allá
de las prácticas de publicación actuales.
Grafoscopio procura brindar un amplificador de voces locales, que apela a lo textual, los datos
y la visualización (y los alfabetismos relacionados con ellos) para dicha amplificación,
como se verá en los capítulos \ref{dataweek} y \ref{prototipos}.

Vemos que lo que se comparte en las diferentes iniciativas ICACG es la búsqueda de apertura, 
transparencia y horizontalidad, pero las preguntas, metodologías y artefactos pueden ser muy 
diversos y con posturas que tienen distintos niveles de diálogo y contrapeso a las dinámicas 
más hegemónicas de la investigación y la ciencia tradicionales institucionalizadas. 
Sin embargo, estos artefactos comparten el hecho de estar descentrados del texto y mediados 
por las tecnologías y representaciones digitales, además de permitir las búsquedas mencionadas.

pues al igual que muchos de ellos combina y provee funcionalidades para la prosa y el código con 
visualizaciones, en libretas y documentos interactivas.
Sin embargo, se distancia de estos al desarrollarse en un entorno continuo de computo, que no
separa en capas disyuntas, lenguaje de programación, entorno integrado de desarrollo (IDE, por
sus siglas en inglés), los gestores de código, la aplicación y el documento, facilitando difuminar
la distinción entre usuario y hacedor (problema central para esta investigación) y usa representaciones 
simbólicas  (código) y gráficas (visualizaciones) para abordar un problema.
El Manual de Usuario de Grafoscopio\footnote{\url{https://is.gd/grafoscopio_manual}} 
(\cite{luna_cardenas_grafoscopio_2017}) muestra en detalle el lugar de este software en medio de las 
otros similares, las ideas de las cuales se inspira y las apuestas de valor agregado del mismo.

Otra tradición importante que Grafoscopio recoge es la mirada tecnopolítica del Software Libre,
pues se acoge a una de las licencias que lo cobijan (la MIT) y explicita, en muchos de los
talleres que se hicieron, la idea de la tecnología digital como una manera de hacer viable (o no)
la idea del conocimiento como bien común.
También expresa las tensiones que estas otras formas de pensar el derecho de autor enfrenta,
pues si bien el código es MIT, su manual (\cite{luna_cardenas_grafoscopio_2017}) emplea la 
licencia de producción entre pares, que alienta relaciones cooperativas y no coloca el usufructo 
de la creación comunitaria y de los comunes en igualdad de condiciones para todos, sino que realiza 
una discriminación positiva para cooperativas y cooperantes.

de los elementos restantes para producir el PDF deben ser instalados localmente en la máquina 
donde se trabaja el documento y para dar cuenta de su historia vía Internet la configuración
en  línea se hizo manualmente, gracias a repositorios en Fossil, además se desarrollo una
funcionalidad puente entre Fossil y Grafoscopio.
En ese sentido, no está dentro de los alcances presentes del prototipo el ser complemente 
portable, ni multiplataforma, y por lo pronto permite de modo autónomo sólo la escritura,
(re)organización del texto en la interface gráfica y su exportación al formato ligero Markdown,
mientras que apela al software externo Pandoc para la conversión a HTML y, junto con \LaTeX,
se puede realizar la exportación a PDF.

Se espera que futuras versiones del software integren los elementos faltantes y puedan 
jalonarlos de maneras progresivas, de acuerdo a las necesidades de la comunidad y los recursos
para ello, siguiendo con la idea de poner a circular e iterar prototipos mínimos y funcionales
desde los cuales detonar dichas experiencias futuras y reevaluar las elecciones de diseño
del pasado.

y referencias bibliográficas integradas por ellos.
Se puede tener un texto sucinto y de fácil lectura, pero que oculta las complejidades que
lo construyen, lo cual dificulta la participación y transparencia posterior, propia de los
procesos de Innovación Abierta y Comunitaria, (como los que alentaba PIAMED) o bien un texto
completo y complejo, que al mostrar sus diversas capas en simultáneo, se enfrenta a la misma
dificultad.




























Además el \emph{IPython Notebook} está hecho en varios lenguajes: Python, C, Javascript 
y HTML, con lo cual la curva de aprendizaje para la intervención de la interface misma se
hace complicada.
Por tanto,  no era muy adecuado como base para explorar la idea de un sistema de escritura 
donde lo arboreo permita lidiar con la complejidad y el caracter emergente de la misma.
Una descripción detallada de las dificultades de lidiar con dicha complejidad incidental,
que toma la forma de diversas tecnologías, lenguajes, \emph{frameworks}, modelos conceptuales

Esta es una muestra interesante de cómo Grafoscopio madura a buen ritmo, sin ser subsumido
o desactualizado por proyectos con mucho más recursos, desarrolladores, apoyo y visibilidad
y que sigue aportando valor diferencial y lugares de interlocución desde los márgenes.
La figura \ref{fig:grafoscopio-jupyter} muestra cómo tanto Grafoscopio como Jupyter Lab 
permiten la integración de distintos elementos de un Entorno Interactivo de Desarrollo, 
yendo más allá de la sóla libreta interactiva.

\begin{figure*}[tb]
	\centering 
	\includegraphics[height={\textwidth}]{./Parte2/narrativa-zooms.png} 
	\caption[Narrativas de datos integradas usando el IPython \emph{notebook}]
	{Narrativas de datos integradas usando el IPython \emph{notebook} (\cite{gil_rojas_narrativas_2014}). 
		En la mitad está todo el documento con la narrativa completa y a los lados dos 
		\emph{zooms} de unos trozos del mismo.
		Los trapecios cyan indican qué parte central es ampliada en el zoom.
		Como se puede ver, un documento único se hace de dificil manejo de todos 
		los niveles que integra la narrativa (descripciones textuales, algoritmos, datos 
		y visualizaciones).
		La opción de separarlo en distintos subdocumentos, no es muy amigable, si en ellos 
		se trabajan los mismos datos y hay que cargarlos una y otra vez, o si a partir de 
		los mismos se crean varios productos derivados dirigidos a públicos distintos, como 
		suele ocurrir.
		Otros autores y practicantes de escritura científica, de datos y de documentos interactivos 
		han ampliado esta crítica al modelo de documentos interactivos que alienta IPython recientemente,
		particularmente cuando se trata de escribir documentos largos, tipo libros.
		(véase \cite{grus_i_2018}, \emph{Why I don't like IPython notebooks})
		La alternativa propuesta con Grafoscopio es usar la escritura interactiva por capas o arbórea,
		que permite ver el todo y las partes en simultáneo a la vez que establecer recorridos a
		medida del árbol para diferentes públicos y ha sido probado en la práctica para la escritura de
		e ingeniería reversa de documentos largos como el propio Manual de Grafoscopio y el Manual de
		Periodismo de datos (\ref{mapeda}).}
	\label{fig:narrativas-ipython-notebook}
\end{figure*}

\clearpage

Para los prototipos de Grafoscopio se preservó la idea de una experiencia de escritura arbórea
centrada en estructura y palabras con una interface sin adornos de Leo, así como la de un
sistema de escritura interactiva, que soportara la recolección y visualización de datos en
concordancia con lo que permite el IPython \emph{notebook}.

\begin{figure*}[tb]%
	\centering
	\subfloat[Trozo mapa del Data Week sobre la relación entre Jupyter y Grafoscopio]{
		\includegraphics[width=0.7\linewidth]{Parte2/jupyter-grafoscopio.png}
		\label{subfig:jupyter-grafoscopio}}
	\\
	\subfloat[Grafoscopio: Panama Papers]{
		\includegraphics[width=0.45\linewidth]{Parte2/data-environment-full.png}

		\ref{subfig:data-environment} Captura del Entorno Interactivo de Desarrollo de Grafoscopio,
		tomada del los Panama Papers en \url{http://is.gd/panama_papers_e}.
		\ref{subfig:ipython-markdown} Captura del Entorno Interactivo de Desarrollo de JupyterLab,
		tomada de \emph{JupyterLab: Ready for Users} en \url{https://is.gd/JRmGNY}.}
	\label{fig:grafoscopio-jupyter}%
\end{figure*}






Se consideraron otros lenguajes con la característica de auto-referencialidad e introspección, 
es decir, el hecho de que el código fuente pueda usarse como datos, de modo que, a su vez, se
pueda usar una parte del código fuente para reprogramar el sistema, en particular su interfaz
y sistema de escritura. 
Dentro de las opciones estaba el editor de código LightTable\footnote{\url{http://lighttable.com/}}, 
que está hecho en ClojureScript\footnote{\url{https://clojurescript.org/}} (un descendiente 

			
			Se dirige a varias categorías de personas:
			\begin{itemize}
				\item
				investigadores en el área de análisis de software, minería e
				ingeniería inversa.
				\item
				ingenieros y arquitectos quienes quieren entender sistemas y datos y
				\item
				constructores de herramientas.
			\end{itemize}		
		\end{quote}
%PENDIENTE: Escribir a Alex sobre la versión que decía esto:
	\item El proyecto de Visualización Agil, construido sobre estas plataformas, 
		afirma (``Agile Visualization'' n.d.):

una de las ventajas fundamentales de entorno continuo de programación ofrecido por Pharo, 
en el que no se diferencia entre la aplicación, el entorno de desarrollo y el código fuente,
pues si se encuentra una funcionalidad interesante, es posible acceder a sus instrucciones y 
copiarlas o modifcarlas hasta lograr una experiencia de uso cercana a la deseada.

En este periodo inicial se aprendió esencialmente sobre la jerarquía de clases, la definición
de objetos y métodos (\cite{bergel_deep_2013}) y el uso de colecciones (\cite{noauthor_pharo_nodate})
y cadenas de texto  (Sharp [1997]), % \cite{sharp_smalltalk_1997} ~\cite{sharp_chapter_1997} , <-- No funcionan!
que permitieron definir el modelo y comportamiento base para sobre ellos hacer la Interfaz Gráfica 
de Usuario (GUI, por sus siglas en inglés).

\begin{figure}[th]
	\begin{center}
		\includegraphics[width=\linewidth]{Parte2/arbol-ayuda-pharo.png}
		\caption[Sistema de ayuda de Pharo]
		{Sistema de ayuda de Pharo. Se puede ver que formar una jerarquía se hace programando. La idea de Grafoscopio era evitar eso para 
			que cualquiera pudiera crearlas desde una interface gráfica

\ref{ui-auto-actualizar}).
Desnudar al problema para llegar a su escencia fue proceso que tardó casi semana y media y fue 
de los más demorado de entender y programar en mi posición de novato.
Sin embargo, esta experiencia de un ejemplo funcional mínimo que representara la esencia del
problema, para pedir ayuda en las comunidades de Pharo o brindarla en las comunidades locales,
demostró ser un aprendizaje clave para el futuro.

\begin{figure*}[tbh]%
	\centering
	\includegraphics[width=0.45\linewidth]{Parte2/autoactualizacion-en-navegador-minimalista-panel-original.png}
	\qquad
	\includegraphics[width=0.45\linewidth]{Parte2/autoactualizacion-en-navegador-minimalista-panel-actualizado.png}
	\caption[Navegador minimalista para probar la auto-actualización]
	{Navegador minimalista para probar la auto-actualización. Izquierda, 
		en su estado original, como estaban los dos desde el código. Derecha actualizado. 

%	etc) por fuera del documento
Más detalles en el capítulo \ref{prototipos}.}.
Las preguntas sobre este formato y sus optimizaciones fueron surgiendo de a pocos, primero garantizando
la posibilidad de guardado y recarga de documentos y luego, su uso eficiente, varios meses despues,
logrando comprensiones de casi 150 veces el tamaño de los primeros archivos.
%PENDIENTE: Referencias a los manuales dentro de este documento.

\begin{figure*}[tb]%
	\centering
	\subfloat[Explicación de la simulación]{
		\includegraphics[width=0.45\linewidth]{Parte2/multiagentes-2.jpg}
		\label{subfig:multiagentes-2}}
	\quad
	\subfloat[Ejecución de la simulación ]{
		\includegraphics[width=0.45\linewidth]{Parte2/multiagentes-3.jpg}

Gracias a STON, la persistencia fue muy fluida y sólo tomo cerca de una decena líneas de código. 
En la figura \ref{persistencia} se ven una captura de pantalla de un trozo del árbol que 
representa la estructura completa de las primeras versiones preliminares para este escrito,
incluidos nodos invisibles y otros metadatos, y, aprovechando su brevedad, el código que 
implementa la persistencia del árbol en disco duro (disponible desde la opción de menú 
``\texttt{Notebook\ \textgreater{}\ Save\ as...}'').

\begin{figure*}[tb]%
	\centering
	\subfloat[]{
		\includegraphics[width=0.35\linewidth]{Parte2/arbol-detalle.png}
		\label{subfig:arbol-detalle}}
	\qquad
	\subfloat[]{
		\includegraphics[width=0.57\linewidth]{Parte2/persistencia-guardar-como.png}

capítulos o nodos invisibles.
Esta realimentación entre el software de escritura y (d)escribir el software dentro de sí mismo
genero este ciclo virtuoso en el diseño del prototipo.
Una descripción detallada de este proceso está en el apendice \ref{materialidades}, debido a su 
caracter clave durante toda esta investigación y sus repercusiones en otras investigaciones y 
prácticas comunitarias venideras.


	\begin{figure*}[tb]
		\centering
		\subfloat[]{
			\includegraphics[width=0.6\linewidth]{Parte2/interface-grafoscopio.png}
			\label{subfig:grafoscopio-articulo-fuente}}
		\\
		\subfloat[]{
			\includegraphics[width=0.6\linewidth]{Parte2/articulo-pdf.png}

			La figura \ref{subfig:grafoscopio-articulo-pdf} muestra ese texto exportado como artículo en PDF.
			La figura \ref{subfig:grafoscopio-manual}, muestra, a la izquiera, una de las interfaces más
			maduras y recientes, que se ha mantenido estables desde el 2017, y a derecha  el Manual de 
			Usuario de Grafoscopio, que fue escrito dentro del mismo Grafoscopio, haciendo uso de las
			funcionalidades mostradas en tal interfaz.}
		\label{fig:versiones-grafoscopio}
	\end{figure*}



La integración experimental con referencias bibliográficas se hizo a través del gestor de código 
abierto Zotero vía Bibtex y las etiquetas \texttt{{[}@autor{]}} colocadas dentro del texto, que soporta 
el Markdown extendido de Pandoc (véase figura \ref{integracion-zotero}).
Las referencias bibliográficas eran almacenadas en línea desde Zotero, a través de su integración 
con Firefox. 
También se colocaban metadatos y se hacían anotaciones y luego eran exportadas a formato BibTeX. 

TeXstudio\footnote{\url{https://www.texstudio.org/}}, los prototipos tempranos de dicho flujo,
que integra Grafoscopio y un soporte robusto para referencias bibliográficas permitieron ver
los alcances y posibilidades al respecto para este software e incluso se preservaron
partes del mismo para el trabajo con TeXstudio, como la integración con Zotero vía BibTeX.
A su vez, probar TeXstudio y usarlo extensivamente permitirá realimentar Grafoscopio con
ideas de uso e interfaz a futuro.


\afterpage{
	\begin{figure*}[tb]%
		\centering
		\subfloat[Zotero integrado en Firefox]{
			\includegraphics[width=0.8\linewidth]{Parte2/zotero-firefox.png}
			\label{subfig:zotero-firefox}}
		\\
		\subfloat[Depurando bibliografías de Zotero en Pharo]{
			\includegraphics[width=0.8\linewidth]{Parte2/zotero-pharo-debug.jpg}
			\label{subfig:zotero-pharo-debug}}
		\\
		\subfloat[La colección de Zotero creada para el doctorado y la maestría con casi 3500 items.]{
			\includegraphics[width=0.6\linewidth]{Parte2/zotero-phd-master.png}
			\label{subfig:zotero-phd-master}}
		\caption[Integración preliminar con Zotero]{
			Integración preliminar entre Grafoscopio y el gestor bibliográfico Zotero. 
			\ref{subfig:zotero-firefox} Zotero  utilizado como plugin del navegador Firefox 
			al comienzo de la escritura de este capítulo.
			\ref{subfig:zotero-pharo-debug} Inicio de la depuración en Pharo de la bibliografía
			para soporte de llaves bibliográficas personalizadas.
			\ref{subfig:zotero-phd-master} Colección/grupo de Zotero creada para el doctorado y la
			maestría, al final del artículo con cerca de 240 items y del doctorado con 3495 items.
			Ver \url{https://is.gd/zoterophd}.}%
		\label{integracion-zotero}%
	\end{figure*}
	\clearpage
}



La colección de literatura recopilada para este escrito alcanzó a tener
cerca de 240 item, si bien se citó sólo una fracción de los mismos. 
La colección en este caso es diversa y cubre temas de ciencia abierta y
reproducible, programación en Smalltalk, visualización de datos y luego se
extendió a otros temas y se abrió tempranamente para la participación de otros
estudiantes de postgrado en Diseño de la Universidad de Caldas, tanto de maestría 

También se incluye en dicho repositorio otro material integrado al mismo, como gráficas y 
figuras y archivos de citación bibliográfica, que permiten rastrear la historia de tales 
recursos y cómo se vinculan entre sí.
De este modo, los textos allí hospedados son consistentes con los principios de trazabilidad
y reproducibilidad de la ICACG, acá mencionados, permiten la participación desde dinámicas
comunitarias y facilitan un puente entre estas y otras prácticas académicas de frontera respecto
a artículos de software que se pudieran someter a revisión de pares y publicación.

\begin{figure*}[tbh]
	\includegraphics[width=0.7\linewidth]{./Parte2/grafoscopio-web.png}%
	\caption[Parte de la página Web Grafoscopio]
	{Parte de la página Web Grafoscopio en \url{http://mutabit.com/grafoscopio/}.
		Dicha página tiene también una versión en inglés en \url{https://is.gd/grafoscopio_e}.
		Sin embargo, las versiones más actualizadas se hacen primero en español,
		suguiendo una apuesta por priorizar lo local.
		Tomado de \cite{luna_cardenas_grafoscopio_2014-1}.}%
	\label{fig:grafoscopio-web}%
\end{figure*}

Por ejemplo, el sitio web de Grafoscopio (\cite{luna_cardenas_grafoscopio_2014-1}\footnote{\url{http://mutabit.com/grafoscopio/}}, 
véase figura \ref{fig:grafoscopio-web}) surgió como una página web de bienvenida, que brindara 
una primera información importante y panorámica sobre el mismo.
Grafoscopio, según su sitio web, es una herramienta amoldable para investigación y publicación
reproducible y para narrativas computacionales que combinan prosa, código, datos, y visualizaciones,
usada en campos diversos, entre los que están el activismo de datos, las visualizaciones de dominio
específico y ejercicios de ciudadanía digital.
Puede ser ejecutada en una amplia varidad de software, desde memorias USB hasta computadores modestos
y servidores.
El sitio web también contiene enlaces a manuales, documentación, muestras de lo que es posible 
y canales de comunicación, soporte y vinculación comunitarios, así como enlaces al código fuente
tanto del software como de la documentación.












%PENDIENTE > Conclusiones: Priorizar lo local

Por otro lado la publicación del artículo indexado titulado 
\emph{Grafoscopio: A moldable tool for literate computing and reproducible research},
en el \emph{Journal of Open Source Software} (JOSS), fue escrito pensando en dinámicas 
académicas innovadoras que vayan más allá del artículo indexado ``clásico'' y empiecen a 
mostrar otros objetos no hegenónicos de conocimiento, para los cuales la descripción en palabras, 
no sólo es insuficiente, sino incompleta e inadecuada comparada con otras formas de publicación
disponibles, como las del software mismo\footnote{Obsérvese acá que la crítica no es a la
	escritura como objeto profundo, sino a la publicación académica indexada actual,
	que no muestra muchas de las profundidades de esa escritura, ni valida otros objetos
	en los que el texto escrito en prosa no es la forma principal de expresión del conocimiento,
	por ejemplo el software, los ensayos sonoros y otros.
	Esta crítica a las actuales formas de publicación se han unido ya varias voces que hablan
	de diversificar aquello que es publicable e indexable, como una forma de diversificar las
	voces y sujetos que participan de los ciclos de la ciencia y la investigación.}.


Como se dijo al comienzo del capítulo, es una muestra de que las prácticas ad-hoc referidas
al objeto de investigación y la investigación reproducible, en particular de indexación e
identidad, pueden cristalizar, a través de Grafoscopio, en objetos más formales que hacen
parte de los ciclos de publicación internacionales y las prácticas de frontera emergentes
en dichos ámbitos.

\begin{figure}[!tbh]

las maneras en que el software da cuenta de dichos procesos y cómo puede describirlos de maneras más 
versátiles y potentes.\footnote{El anexo \ref{materialidades} ``Diálogo de Materialidades'' da cuenta 
	de maneras más detalladas de este fenómeno, que es una de las bases del proceso de 
	\emph{boostrapping} que permite hacer puentes, de doble vía, entre la escritura de prosa y la 
	de código.}
%PENDIENTE: Diálogo de materialidades.

La escogencia de idiomas para el material presente el en repositorio, pasaba del
español al inglés dependiendo de los públicos y participantes objetivo para dicho
material, elegiendo español para públicos y eventos locales e inglés para los internacionales.
Sin embargo, se dio prioridad a lo local en general, produciendo y actualizando el
material en español y luego haciendo traducciones al inglés (salvo en aquellos que
fueron escritos originalmente en inglés, pues sus públicos eran internacionales).

\begin{figure*}[tbh]
	\includegraphics[width=\linewidth]{./Parte2/grafoscopio-user-manual.png}%
	\caption[Parte del manual de Grafoscopio]
	{Parte del Manual de Usuario Grafoscopio, hecho dentro de Grafoscopio mismo. 
		Disponible en \url{https://is.gd/grafoscopio_m1}. 
		Tomado de \cite{luna_cardenas_grafoscopio_2017}.}%
		\label{fig:grafoscopio-manual}%
\end{figure*}








Sitio web, manual de usuario, y artículos académicos, hacen parte del mismo repositorio 
de código fuente, lo cual permite a la comunidad, ver las distintas caras y artefactos 
relacionados con Grafoscopio y su carácter polisémico.
Incluso a futuro, gracias al soporte que está brindando la comunidad de Pharo para integrar
el código fuente del software en repositorios convencionales en lugar de especializados,
sería posible integrar este repositorio de documentación con el de 
software\footnote{\url{http://smalltalkhub.com/\#!/\~Offray/Grafoscopio}}, brindando

trazando la historia de mi pertenencia a dichas comunidades; y por otro desde como
dicha cultura encarna en el hackerspace HackBo, donde esta investigación ocurre,
caracterizando maneras de hacer en la comunidad de práctica y colocando lo anterior en 
diálogo con perspectivas teóricas y críticas que dan cuenta del fenómeno hacker como una 
definición abierta que puede ser leída como práctica ciudadana y cotidiana.

Si bien se tocarán algunos prototipos de manera tangencial, en énfasis en los mismos
se hará en los capítulos siguientes, que mostrarán las sucesivas interaciones de ellos,
en el contexto comunitario e interpersonal antes mencionado, dándo cuenta así de los
procesos de investigación no líneal mencionados por Leinonen, en los que la indagación
contextual y diseño participativo en comunidad, pasa por ciclos privados de trabajo por expertos, 
que luego producen prototipos que regresan a la comunidad.

\section{Mi lugar en la comunidad}\label{mi-lugar}

La metodología de esta investigación, al igual que algunas mencionadas en la primera
parte, está \emph{informada} etnográficamente (sin ser del todo una investigación
etnográfica) y por ello es importante establecer mi lugar en la comunidad.
Para esto lo ubicaré en dos ejes: uno de ellos como activista y miembro

``la gente usa el lenguaje para describirse a sí misma y sus relaciones con los otros y 
cómo el lenguaje los convoca a hacer cosas con palabras y palabras con cosas que los enactuan 
a sí mismos''.
Para estos autores esta configuración desde la auto-descripción y la auto-convocatoria 
(de la gente hacia y para la gente) implica entender cómo actuán en Internet, no sólo frente 
a cómo hablan, sino desde cómo se involucran y actuan desde dicha red y en conexión con el
mundo fuera de ella, pero interconectado con la misma.

Así, en la medida en que las fuerzas de obediencia, sumisión y subversión están 
presentes en los ciudadanos, estos no solo están sujetos \emph{al} poder, sino que son sujetos
\emph{de} poder, pues la presencia de una fuerza no excluye las otras.
Dicho poder lo ejercen de distintas maneras, atendiendo a `actos de verdad' en los
que se manifiestan sus personas políticas y que dan cuenta de esa miriada de actos,
prácticas y pensamientos que atienden al llamado sobre cómo gobernarse a sí mismo,
por un lado, y por otro hacen del sujeto que se pregunta eso, el lugar y laboratorio
primero de las exploraciones y respuestas sobre el autogobierno.

--[[ 
  I'm the manifest of a set of LaTeX files.
  I'm used to create a cryptographic hash, i.e. a unique number and letters combination 
  to designate a set of files.
  I'm created by running the script revmarker.lua
]]
["materialidades","dataviz-infra","pre","preface","introduction","parte1","math","modelling-background","nd-modelling","parte2","parte3","operations-background","extrusion","incremental-construction","linking-lods","slicing","cleaning","conclusions","dictionary","summary","cv"]

% !TEX root = tesis.tex

%----------------------------------------------------------------------------------------
%	PARTE 1
%----------------------------------------------------------------------------------------

\part{Perspectivas teóricas, críticas y metodológicas}
\label{part:perspectivas}

\restoregeometry

\emph{¿Cuál lugar ocupa esta tesis, desde lo epistemológico, axiológico y metodológico?} 
Esta será la pregunta que se abordará en esta sección.

Para ello se realizará una panorámica de las distintas
epistemologías, se sugerirá una manera de conectarlas
y se usará una aproximación de \emph{zoom} para modificar la teoría de diseño de
\cite{jonas_design_2004,jonas_design_2007}, conectándola con la perspectiva crítica de 
\cite{fuchs_autopoiesis_nodate}, cambiando el énfasis en lo social, de lo comunicativo a lo humano, 
lo cual tiene repercusiones en cómo se puede investigar desde y para el diseño, específicamente 
permitiendo concebir aproximaciones metodológicas al diseño que suponen al investigador/diseñador 
como sujeto político, que co-diseña y habita un problema/prototipo
dentro de una comunidad (de práctica o interés) apostando
por un mundo más plural e incluyente, es decir apostando por una axiología particular.
Se finaliza con una metodología de diseño basada en investigación, 
que propone al software como hipótesis, lo cual conecta las epistemologías
del diseño, contextuales y no orientadas a producir saberes
positivistas y verdades, sino saberes contextuales e hipótesis,
con la forma que tales hipótesis toman como artefactos de software
desarrollados dentro de una comunidad.
Esto permitirá entender los lugares de mirada

y los individuos en ellas dejen de persistir, al margen de la popularidad.
Son artefactos que hacen sentido para las personas y colectivos alrededor
de ellos, que los usan y los (re)hacen de modo permanente y abordan 
de modo paralelo dos los problemas planteados por Sanders, pues el sentido 
y la filiación ayudan a resolver en simultánea el deseo y la utilidad.
Algo similar se puede decir del quehacer artesanal, que se centra en
lo útil, bello y usable, sin pretensiones grandilocuentes, sino ocupándose
los problemas desde la unidad del hacer-pensar que menciona \cite{sennett_artesano_2009}.
Sin embargo, esta otra mirada del diseñar como actividad inherentemente
humana no ocurre centrada en las comunicaciones,
sino en los actos de sentido de las personas y las comunidades de práctica
que constituyen y habitan, es decir está centrada en lo humano y su relación
con el mundo.

Las comunidades de práctica son un puente que no sólo permiten pasar de

%----------------------------------------------------------------------------------------
%	CHAPTER 2
%----------------------------------------------------------------------------------------

\chapter{De todos los mundos posibles, uno potenciador de lo humano, emancipador y construido en comunidad}\label{mundos-posibles-humanos-comunitarios}

En la diversidad de saberes y perspectivas epistemológicas que hay
en diseño, tanto las mencionadas brevemente al comienzo de este escrito como
muchas que no, hay una cosa el común: el diseño es una actividad humana que 
se ocupa del mundo posible.
La búsqueda de dicho mundo tiene dos preguntas importantes:
¿Cuál mundo de entre todos? y ¿Cómo lo creamos? Si estas preguntas reflejan preocupaciones
claves para el diseño, la formación doctoral en diseño debería ayudarnos a contestarlas,
así que el papel de la investigación en las tentativas de solución a esas
dos preguntas, también es un tema de esta sección.

Las secciones precedentes nos permitieron un recorrido que nos deja ahora

	esta realidad en interacciones con el otro.
	Nuestro abordaje puede ser clasificado como una variedad del realismo crítico''.
\end{itemize}

No creo que todas las preguntas preguntas sobre el deseo o lo bello, o el poder
se puedan colocar en perspectiva materialista. 
Pero indudablemente el diseño debe ocuparse de un mundo posible
con mayores garantías para la busqueda de sentido y potencial personal y comunitario
para todos y todas y con el sostenimiento y diversidad de la vida presente\footnote{
	No me ocuparé acá de si queremos diseñar otras creaturas vivas, pues no es el
	texto ni el momento para abordarlo, sin embargo, el sostenimiento de la
	vida presente, salvo los supervirus y otros entes vivos por el estilo
	si me parece una compromiso asumible. Las negociaciones en la diversidad podrían
	terminar con alguna de ella y son un tema sensible para el cual no hay espacio
	suficiente}

\restoregeometry

En la primera parte se habló de como el diseñador ``habitaba el prototipo'' cuando se
acercaba a las comunidades y codiseñaba con ellas.
También se reconoció el caracter de investigador como sujeto político, que no
intenta describir objetivamente un fenómeno, sino que está involucrado con él
íntimamente.
Una metodología consecuente con esta forma de conocer 
% está de la mano de las epistemologías feministas y se 
crea un viraje desde la observación participativa a la participación observante. %REF: participatory observation

Los capítulos de esta segunda parte describen el problema y los prototipos 
desde esa perspectiva inmersa en la comunidad y si bien inician con una pregunta/objetivo
relativamente claro en esta narrativa organizada que demanda la academia,

El capítulo 5 enfatizan varios ciclos de indagación comunitaria, diseño participativo, 
diseño de producto y prototipo como hipótesis, con los artefactos y dinámicas que antecedieron 
y fueron clave para la creación de Grafoscopio y el Data Week, mientras que los capítulos 
6, 7 y 8 dan cuenta de los mismos ciclos para los artefactos y dinámicas centrales 
de esta tesis: el capítulos 6 se centra en Grafoscopio, el 7 en las dinámicas 
comunitarias que lo configuraron y se dieron gracias a este y el 8 en los
protipos individuales y colectivos que muestran la amplificación de voces críticas
gracias a Grafosocopio y el Data Week, que efectivamente nos cambiaron en la forma
de realizar prácticas ciudadanas, desde los artefactos digitales que podíamos desplegar,
intervenir, interconectar y transformar.
Lo anterior evidencia como los ciclos de realimentación de las fases de la investigación
basada en diseño producían prototipos de software que se iban modificando progresivamente
hasta llegar a aquellos que se consolidaron finalmente y cómo se entrelazan con
las dinámicas comunitarias y los cambios en ellas.
Obsérvese que la intensión no es evaluar los prototipos desde una mirada positivista
y reduccionista, sino dar cuenta de cómo ellos consolidan comunidades alrededor y
las transformas, junto a interpretaciones críticas del proceso.

El recuento de esas transformaciones en esos cinco capítulos de la segunda parte es el 
recuento del despliegue de la metodología de esta tesis, que acá se pone en diálogo 
recurrente con perspectivas críticas, teóricas y tecnológica.
Mientras la primera parte es más teórica y no se centra mucho en tecnologías o artefactos
específicos, esta segunda parte es más práctica y se centra en ellas.
Sin embargo además de ciertas interpretaciones teóricas a lo largo de estos capítulos,
la mayoría cierra con un breve recuento que conecta el capítulo con la teoría de la primera
parte, preparando el diálogo que se presenta en la tercera parte.

\input{hacker}

\input{prehistoria}

\input{grafoscopio}

\input{dataweek}

\input{prototipos}

Este capítulo cierra la tesis recogiendo los resultados y hallazgos, reflexionando
sobre ellos y las conexiones con otras investigaciones venideras y futuralidades.

\section{Problemas difusos, prototipos y ciudadanías}

Al comienzo de esta tesis se afirmó que el diseño era un saber en red, con epistemologías
particulares, que se ocupaba de problemas difusos (con enunciación difícil), en los que los prototipos 
son, a la vez, un laboratorio, para explorar los problemas y llegar a hipótesis plausibles y un medio 
para comunicar tanto el problema como las hipótesis sobre este (\cite{saikaly_approaches_2005}).

Dentro de las múltiples epistemologías en diseño, se adoptó una desde la perspectiva de 
\cite{jonas_design_2004, jonas_design_2007}, que habla del diseño como un puente entre entidades de 
caracter autopoiético, que se crean a sí mismas (lo mental, lo social y lo biológico) y heteropoiético, 
que son creadas por otras (los mecanimos y lo artefactual), estableciendo un aporte desde la crítica de 
\cite{fuchs_autopoiesis_nodate} a la teoría social de Luhmann, empleada por Jonas como base y cambiando 
el fundamento de lo social de las comunicaciones a lo humano, revisando las consecuencias de dicho cambio 
en la teoría original y derivando implicaciones para esta tesis, tanto axiológicas y metodológicas, respecto 
al investigador como sujeto político y las comunidades como exploradoras de mundos posibles en los que este 
investigador se encuentra implicado profundamente, extrapolando las ideas de \cite{manzini_emerging_2013} 
sobre innovación social emergente.
Algunas de las tensiones que Jonas planteaba originalmente se resolvían desde este nuevo enfoque,
particularmente la naturaleza contingente de los artefactos, pues dicha naturaleza daba cuenta de
como ellos podían ser reconfigurados o recreados particularmente estudiando puntos de bifurcación
históricos y mezclando tradiciones, ahora con el beneficio del conocimiento en retrospectiva.
También vimos que otras tensiones exploradas sobre la belleza y la utilidad eran revertidas en las 
comunidades de práctica, donde lo útil predomina, así no se adecue a las estéticas más generalizadas 
de lo bello.

con lo cual aumentarían su autonomía y su capacidad de agencia.
Los primeros artefactos eran web, debido al auge de la misma y construidos en Python, y aunque
tenían esa propiedad de ser modificados en ejecución desde el artefacto mismo (gracias al framework
que empleé para construirlos, web2py), sus usos fueron instrumentales y no convocaron
al grueso de la comunidad de HackBo a modificarlos activamente, una vez los usos básicos estuvieron
listos.
Esto llevó a exploraciones más arriesgadas desde tecnologías con un caracter auto-referencial,
más explícito, si bien menos populares, como Pharo, que permitió escribir Grafoscopio de modos mucho
más fluidos que los explorados previamente en los talleres de Indie Web Science (que modificaban o
extendían IPython con web2py), marcando, desde su modificabilidad extrema, una diferencia importante 
con otros sistemas que se enmarcan en búsquedas similares (véase capítulo \ref{grafoscopio}).
También se establecieron aproximaciones consecuentes con las epistemologías de diseño que se
relacionan con el prototipo y la comprensión desde la acción, alejándose de perspectivas más
ingenieriles y aproximándose a aquellas más artesanales (\cite{sennett_artesano_2009}), incluso
asociadas a cómo se entiende y hace el software (\cite{blackwell_craft_2015}).
Además se lanzó un ciclo de \emph{bootstrapping} en el que un software para escribir (Grafoscopio),
era empleado para escribir sobre el software (artículos y manuales) al comienzo y luego sobre
otros temas de investigación y activismo, incluyendo varias visualizaciones (revisandos en el capítulo 

cuenta de un conjunto de tensiones dentro de los procesos comunitarios, particularmente en las
comunidades de software libre respecto a pocos autores activos y una comunidad de participación 
periférica.

Estas dinámicas de participación con sus tensiones y posibilidades, permite retomar o crear nuevos
prototipos que a su vez amplifican las posibilidades de las comunidades de base de interactuar
con instituciones públicas e iniciativas internacionales (como se mostró en detalle en los 
capítulos \ref{dataweek} y \ref{prototipos}).
Es decir que la pregunta difusa sobre cómo cambiamos los artefactos que nos cambian, muestra
un conjunto de cambios detonados por el prototipo inicial de Grafoscopio en la comunidad original
donde este se desarrolla, convocando a una comunidad más pequeña, que atiende un conjunto de
convocatorias (o llamamientos dentro de los actos digitales de \cite{isin_being_2015}) que les
permiten consolidarse como comunidad y también realizar un conjunto de aperturas (de nuevo citando
a Isin y Ruppert) de participación e infraestructuras en interacción con gobiernos y otras comunidades.
Estos cambios no estaban previstos en la pregunta original, sino que se desarrollaron de manera

sino a cómo esta amplificaba sus voces como comunidad.
El caracter de meta-sistema de Pharo alentó prácticas ágiles\footnote{Mucho más ágildes de las
	que se probaron con otros lenguajes como Python, en los primeros estados de la metodología} 
(de visualización, documentación y modificación de los artefactos) que permitieron a una comunidad
nacientes de hackers cívicos configurarse como tal y amplificar sus voces desde las tecnologías
digitales explicitando un diálogo estructura-agencia y cómo el diseño puede facilitar transiciones
hacia otros mundos donde varios futuros convivan, en lugar de aquellos que sólo ven las tecnologías
digitales de manera enajenante, específicamente desde miradas capitalistas neoliberales que tienen
a hacer los mundos convergentes en uno sólo, denunciados por \cite{escobar_autonomiy_2016}.
Esta tesis muestra una manera específica en que al cambiar los artefactos que nos cambian, participamos
de otros diseños en la forma de ser (de comunidades y sus participantes) o diseños ontológicos, de 
interlocutar (desde y entre las comunidades y hacia las instituciones) y en ese sentido se alinea
con los diseños para la autonomía.

En este difícil balance entre teoría y práctica que la tesis intenta, habría que trazar un derrotero
sobre los cambios futuros en artefactos y dinámicas que la tesis muestra y sobre las investigaciones

\vfill
\pdfbookmark[1]{Comité doctoral}{thesis:committee}

\noindent Esta disertación ha sido aprobada por

\medskip\noindent
\begin{tabular}{@{}ll@{}}
  \quad{}Jurado 1: & Dr.\ Eduardo \ Navas \\
  \quad{}Jurado 2: & Dr.\ Alexis \ Guerra \\
%\\
%\multicolumn{2}{@{}l@{}}{Composición del comité doctoral:} \\
%\\
%  \quad{}Nombre & cargo \\
%  \quad{}Prof.\ dr.\ J.\ Stoter & Delft University of Technology, promotor \\
%  \quad{}Dr.\ H.\ Ledoux & Delft University of Technology, copromotor \\
%\\
%\multicolumn{2}{@{}l@{}}{Miembros Independientes:} \\
%\\
%  \quad{}Prof.\ dr.\ E.\ Eisemann & Delft University of Technology \\
%  \quad{}Prof.\ dr.\ M.\ van\ Kreveld & Utrecht University \\
%  \quad{}Dr.\ R.\ Lindenbergh & Delft University of Technology \\
%  \quad{}Prof.\ dr.\ ir.\ A.\ van\ Timmeren & Delft University of Technology \\ 
%\\
%\multicolumn{2}{@{}l@{}}{Otros miembros:} \\
%\\
%  \quad{}Dr.\ G.\ Damiand & Claude Bernard University Lyon 1 \\
\end{tabular}

%This research was supported by mutabiT S.A.S a small famility enterprise 


\begin{custom-dedication}

por su soporte para referencias bibliográficas, notas al pie, metadatos expresado en YAML; la 
integración con el gestor blbiográfico Zotero para manejar dichas referencias y la creación de 
una colección abierta en el mismo para el doctorado, (que alcanzó más de 3400 items desde entonces), 
así como reiterar el uso de Fossil, un sistema de control de versiones distribuido, minimalista, 
autocontenido ligero y fácil de usar para publicar archivos de textos, imagen, código fuente y 
su historia. 
En un repositorio público de Fossil, que había creado para el doctorado desde el 2011, coloqué 
los escritos hechos y exportados desde Leo\footnote{véase: \url{https://mutabit.com/repos.fossil/doctorado-offray/}}, 
y que ha contenido la historia de varios artefactos creados durante el mismo, incluida esta misma tesis.

Las piezas de infraestructura se estaban juntado.
Pero la infraestructura misma era un medio y un fin para comunicar y explorar las ideas 
sobre autonomía, cumpliendo los postulados de \cite{saikaly_approaches_2005}, y los 
prototipos desarrollados en ella permitían recorridos específicos en los que las
infraestructuras cambian y se combinan para permitir argumentos más específicos sobre

Latinoamérica (específicament México) con similitudes sorprendentes, a pesar de que consideraban 
el activismo en el mundo editoral y no en el de los datos. 
Entre tales similitudes estaban: el uso de los mismos lenguajes de etiquetamiento ligeros 
(Markdown y Pandoc), la crítica al procesador de palabras y otros software comerciales, el hecho de 
que la lectura y escritura ahora se hace desde y para dispositivos multi-pantalla (computadores, tabletas).
Este proyecto configuró así aprendizajes que perdurarían y se consolidarían en esta práctica de escritura 
y otras venideras (váse sección \ref{bidibog} y el capítulo \ref{conclusiones-y-posibilidades-futuras}).

\begin{figure*}[tbh]
	\includegraphics[angle=-90, width=1.1\linewidth]{./Parte2/pandoc-diagram.jpg}%
	\caption[toc]
	{Formatos de entrada y salida permitidos por Pandoc.
		Arriba los formatos de entrada, abajo los formatos de salida.
		La gráfica ampliada se puede ver en \url{https://pandoc.org/}.
		El acceso a todos estos formatos y la automatización para ellos se abrió, gracias a 
		los \emph{scripts} en Lua, realizados para el proyecto del Manual de Periodismo de Datos 
		e integrados en Grafoscopio.}%
	\label{fig:pandoc-diagram}%
\end{figure*}

La automatización para las tareas de apertura del Manual implicó el uso de lenguajes externos
a Pharo, particularmente Lua\footnote{\url{https://www.lua.org/}}, que ya viene incluido en Pandoc,
y que permite acceder y programar la funcionalidad del mismo, incluyendo el acceso al árbol del
documento que emplea Pandoc para representar los formatos que reconoce y también realizar 
transformaciones entre ellos.
De este modo las ideas de los participantes se pudieron implementar de maneras más elegantes,

que constituyen tanto Pharo como Lua y las capacidades de metaprogramación.
Poner estos dos extremos complementarios en diálogo a través de proyectos específicos y
prácticos, como este Manual, de modo que se aprovecharan las fortalezas de cada uno y se
mostraran a los asistentes diversos paradigmas de programación, fue una exploración
interesante y primera, que valdría la pena extender en futuros proyectos, como
la extensión de Brea (véase \ref{brea}).

\begin{figure}[tb]
	\includegraphics[width=0.8\linewidth]{./Parte2/grafoscopio-code-permisos.png}%
	\caption[Permisos en el repositorio de código de Grafoscopio]
	{Detalle sobre los permisos en el repositorio de código de Grafoscopio expresado en 
		su línea de tiempo.
		En general la política sobre los permisos para enviar nuevas versiones del código fuente
		(\emph{commits}) fue extremadamente abierta: si alguien durante las sesiones de programación
		en multitud \emph{mob programming}construía código que fuera funcional respecto a alguna 
		característica deseada, podía obtener tales permisos de modificación del código fuente, 
		usualmente primero en el paquete Dataviz y luego en el de Grafoscopio.
		Nótese cómo los \emph{committers} se diversifican por un periodo de tiempo, antes de volver
		a la autoría mayoritariamente individual.}%
	\label{fig:grafoscopio-code-permisos}%
\end{figure}

También fuimos asignando permisos en el repositorio de código de Grafoscopio, (no sólo en el 
de documentación del Manual), de modo que los ejercicios de programación en multitud antes
referidos fueran registrados en dicho repositorio por múltiples participantes, reconociendo
sus aportes y mejorando las contribuciones hechas por ellos (véase figura \ref{fig:grafoscopio-code-permisos}).
Sin embargo, tanto en los repositorios de software, como en los de documentación, los
aportes fueron realizados durante los eventos y se volvieron individuales luego de los mismos,
siguiendo las dinámicas habituales.
Otras formas de contribución se sostuvieron luego del evento, por un grupo pequeño de participantes,
(comparado con el total de inscritos en la lista de correo o la de telegram, pero consecuente con el
número de personas que asistían a las Data Rodas) además de las conversaciones sobre edición ramificada, 
como entradas a blog\footnote{\url{https://is.gd/mapeda_blog}}, charlas en Telegram  o por la lista al 
respecto de dicha actividad.
Otros miembro de la comunidad de Grafoscopio sugirió e implementó la propuesta de un Club de 
Lectura para el Manual\footnote{\url{https://is.gd/mapeda_club}} usando el sistema de lectura 
anota vía Hypothesis, al que ya se ha hecho mención.
Sin embargo, dicha lectura anotada en el club es aún un asunto pendiente en la comunidad,
para esta y otras iniciativas.
















Se dispuso una página de portada para el repositorio, que mostraba las diferentes variantes
del Manual (PDF, EPUB, código fuente en Grafoscopio y Markdown) y la inspiración detrás del proyecto, 
las entradas a blog de un miembros de la comunidad y se dispuso esta información en inglés y en
español (véase figura \ref{fig:mapeda-portada}).


\begin{figure*}[tb]
	\centering
	\subfloat[]{
		\includegraphics[width=0.32\linewidth]{./Parte2/mapeda-pagina1.png}
		\label{subfig:mapeda-pagina1}}
	\subfloat[]{

lo requieran, por ejemplo en el diseño de portadas para libros y otras publicaciones
ramificadas que exploraríamos en el segundo semestre de 2018 y/o 2019, así como
los micrositios web que se desarrollarían para el Diplomado en Activismo de Datos+Codigo
y Ciudadanías Digitales.\footnote{El lector notará que este es aún nombre en contrucción
	y que en otras partes del texto ha sido referido como el Diplomado en Alfabetismos
	y Visualización Críticos de Datos y Código.}

Etico es un miniportal que creé usando algunas de las tecnologías exploradas en Brea 
(Fossil y MDL) cuya función era emplear este tipo de infraestructuras ligeras y resilentes
para  ``[visibilizar] los actos, agentes y lugares éticos cotidianos, en el comercio, 
la producción, el consumo y el gobierno y alertando sobre su ausencia''.
Al igual que Brea, se espera que este ejericio unipersonal pueda escalar a contextos
comunitarios si las condiciones lo requieren.

\begin{figure*}[tbh]
	\centering
	\subfloat[ ]{
		\includegraphics[width=0.45\linewidth]{./Parte2/etico-cuestionables.png}
		\label{subfig:etico-cuestionables}}
	\quad
	\subfloat[]{
		\includegraphics[width=0.42\linewidth]{./Parte2/etico-reconocimientos.png}
		\label{subfig:etico-reconocimientos}}
	\caption[Miniportal Etico]
	{Miniportal Etico. Izquierda, comportamientos cuestionables. Derecha, comportamientos reconocidos.
		Se puede visitar el portal en \url{http://mutabit.com/repos.fossil/etico/}}
	\label{fig:etico}
\end{figure*}










\section{Otros constructos comunitarios}\label{comunidad-artefactos}

A lo largo de las distintas ediciones del Data Week, las Data Rodas y otros encuentros,
se fueron creando otro tipo de constructos comunitarios.
El primero de ellos, y de uso más evidente durante los mismos fueron las libretas
de técnicas para activismo de datos y su compañera la libreta aprendiz, que ya fueron

--[[ 
  I'm useful for traceability of the files involved in the creation of a particular derivated
  file from one or several TeX/LaTeX file sources.
  I can be used to calculate a unique identifier describing the status for all files involved in 
  the creation of a particular derivated file (PDF, DVI, HTML, etc.), using as sources the composition 
  of ona or several TeX or LaTeX files, which can be called from a single root file (the called 
  files there can also do more calls to other files).
  
  I create a 'manifest.lua' file that calculates the checksum for the given root TeX/LaTeX 
  source file and its and does the same, recursively, for all files that are called
  using the '\include{file}' or '\input{file}' command.
  
  Once I have a such tree (a recursively created table of tables with the files),
  I calculated the checksum for the files that are present in the hierachy and in the
  file system, with the folder containend this script as its relative root where all
  other files routes are calculated.
  
  For example if the file main.tex contains the following lines:
  
  \include{myFile}
  \input{../myOtherFile}
  
  I will look for the existence of such files, using as relative root for them, the place
  where this script is located, and if they exits, I will calculate their checksum.
  
  IMPORTANT: I need to be located in the same place where the TeX/LaTeX main source file is
  located, so all relative paths are the same.
  
  Copyright (C) 2018 Offray Luna Cardenas

  Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
  "Software"), to deal in the Software without restriction, including
  without limitation the rights to use, copy, modify, merge, publish,
  distribute, sublicense, and/or sell copies of the Software, and to
  permit persons to whom the Software is furnished to do so, subject to
  the following conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.
]]

local preamble = 
[[ 
  I'm the manifest of a set of LaTeX files.
  I'm used to create a cryptographic hash, i.e. a unique number and letters combination 
  to designate a set of files.
  I'm created by running the script revmarker.lua
]]

function children(fileContents)
    -- I Find all the calls for "\include{parameter}" or "\input{parameter}" on a
    -- string taken from the contents of a LaTeX file.
    local answer = {}
    string.gsub(fileContents,"\\include{([^{}]*)}", function(a)  table.insert(answer,a) end )
    string.gsub(fileContents,"\\input{([^{}]*)}", function(a)  table.insert(answer,a) end )
    return answer
end

function readAll(file)
    local f = assert(io.open(file, "r"))
    local content = f:read("*all")
    f:close()
    return content
end

function createManifestFor(rootFile)
  
  local fileContents = readAll(rootFile)
  local json = require ("dkjson")
  local manifest,err = io.open("manifest.lua", "w+")
  
  if manifest then
    manifest:write("--[[" .. preamble .. "]]\n")
    -- manifest:write(fileContents)
    manifest:write(json.encode(children(fileContents), { indent = true }))
    manifest:close()
    print("Manifest file created. Look the 'manifest.lua' file for more details.")
  else
    print("Error!...", err)
  end
end

createManifestFor("tesis-test.tex")