User:Alexander Roidl/itl proposal: Difference between revisions

From XPUB & Lens-Based wiki
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Project Proposal =
= Project Proposal =


https://pzwiki.wdka.nl/mediadesign/X-Lib
[[XPPL]]
[[File:Screen Shot 2018-05-13 at 22.50.36.png|thumbnail]]
[[File:Screen Shot 2018-05-13 at 22.50.36.png|thumbnail]]
[[File:Screen Shot 2018-05-14 at 23.57.30.png|thumbnail|local use of bibliotecha]]
[[File:Screen Shot 2018-05-14 at 23.57.30.png|thumbnail|local use of bibliotecha]]
[[File:Screen Shot 2018-05-14 at 23.58.21.png|thumbnail|based on JSON structure]]
[[File:Screen Shot 2018-05-14 at 23.58.21.png|thumbnail|based on JSON structure]]
== Interface for Interface ==
== Interface for Interface ==
=== The infrastructure of the library ===
=== The infrastructure of the library ===
 
<onlyinclude>
[[File:Screen Shot 2018-05-27 at 20.06.40.png|thumbnail]]
<!--''what? (250)'' -->
<!--''what? (250)'' -->
For the XPPL I am working on the infrastructure of the library and how to make this structures accessible in a useful but also in a playful way.  
For the XPPL I am working on the infrastructure of the library and how to make this structures accessible in a useful but also in a playful way.  
Line 19: Line 18:
<!--''why is it necessary? (125)''-->
<!--''why is it necessary? (125)''-->
The Library needs a profound structure to be maintainable. A dynamic structure and different ways of access provide for a good basis to keep it alive and to also not display the »only truth« of how books can be stored and interfaced. The API offers the opportunity to query the database and use it in a much wider sense than we can think of now.
The Library needs a profound structure to be maintainable. A dynamic structure and different ways of access provide for a good basis to keep it alive and to also not display the »only truth« of how books can be stored and interfaced. The API offers the opportunity to query the database and use it in a much wider sense than we can think of now.
 
</onlyinclude>
<!--''Relation to project as whole (how does it interface with the rest of the PZI library project)''-->
<!--''Relation to project as whole (how does it interface with the rest of the PZI library project)''-->
The infrastructure of the library provides all the interfaces with the necessary connection to the database. Therefore it connects all the interfaces to it in its database. The library you see is always only a potential interface to it.  
The infrastructure of the library provides all the interfaces with the necessary connection to the database. Therefore it connects all the interfaces to it in its database. The library you see is always only a potential interface to it.  
Line 37: Line 36:
* different access points to the library
* different access points to the library
** interested in how the library opens up to the public
** interested in how the library opens up to the public
== From Reading to Seeing ==
*What is the position of the library?
*Does the library make books visible or readable?
*How can a book be seen in the interface?
*'''How can the library be read?''' -> if the books are inside the library as texts
*Does the digital library prefer the text over the book?


== Ideas & Thoughts ==
== Ideas & Thoughts ==

Latest revision as of 17:50, 9 June 2018

Project Proposal

XPPL

Screen Shot 2018-05-13 at 22.50.36.png
local use of bibliotecha
based on JSON structure

Interface for Interface

The infrastructure of the library

Screen Shot 2018-05-27 at 20.06.40.png

For the XPPL I am working on the infrastructure of the library and how to make this structures accessible in a useful but also in a playful way. The structure of the library is built around a database, that can be accessed from several points and in different ways. The infrastructure is built in such a way, that it can be modified easily. The platform itself will be hosted on a PI, that serves the library. The Library can be interfaced in programmatic as well as in graphical ways. The fundamental basis of the library is the database, but it shouldn’t hide within it self. The library should contain the books not only as downloadable pdf/ebook–book files, but also include the actually text in some form. To »convert[s] an image of a book page back into language – searchable, retrievable, scalable, and translatable. In the future most designers will be creating reading experiences not book designs.« (Blauvelt, 2010) This compiled all together asks the question on how the library can be read.

The library will provide a framework and API to be accessible. It is a self-programmed environment written in python and freely accessible and forkable for anybody. Therefore it integrates the matters of the Experimental Publishing Course perfectly. »Users« (= non registered visitors within the network) are able to contribute to the library. Whereas »Visitors« can only view the catalogue and its structure.

The Library needs a profound structure to be maintainable. A dynamic structure and different ways of access provide for a good basis to keep it alive and to also not display the »only truth« of how books can be stored and interfaced. The API offers the opportunity to query the database and use it in a much wider sense than we can think of now.

The infrastructure of the library provides all the interfaces with the necessary connection to the database. Therefore it connects all the interfaces to it in its database. The library you see is always only a potential interface to it.

This projects connects to my previous interests in databases and how different programming approaches interface differently with the latter. Different ways of reading the database means different interfaces. I want to explore the structure of database driven projects and how these structures can transform.


References:

Blauvelt, A. (2010). From Books to Texts. In: M. Gerritzen, G. Lovink, M. Kampman, ed., I Read Where I Am: Exploring New Information Cultures, 1st ed.* Breda: Valiz/Graphic Design Museum.


  • Interface for Interfaces
  • building the Infrastructure of the library
  • Application programming interface
  • different access points to the library
    • interested in how the library opens up to the public

From Reading to Seeing

  • What is the position of the library?
  • Does the library make books visible or readable?
  • How can a book be seen in the interface?
  • How can the library be read? -> if the books are inside the library as texts
  • Does the digital library prefer the text over the book?

Ideas & Thoughts

required

(sorted by relevance)

  • view books in library
  • upload new books (might also work via scp)
  • sort books (categorize, tag, edit metadata, description, ISBN)
  • search (interface)
  • users (access how and who?)

framework

  • Pi

library as physical object

  • how can we put the PI into space?
  • with display / connected to coffee machine?
  • physical presence also as a reminder -> maintenance


ideas

  • make pdfs available to everyone in local network
  • make structure available to www (tunnel)
  • distributed library (multiple persons have parts of the library)

PDF Reader / Editor in Web

  • Possibilites to edit and view Pdfs in browser
  • access PDFs in terms of search / preview
  • View / Edit without »downloading«
  • https://web.hypothes.is/ for web annotation


Decisions

Using a pi with webinterface Catalog is available online, while files are stored offline and only accessible via the local network. python dictonary -> use shelve python -> API with python

Resources