<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (rybesh)</title>
    <link>https://pinboard.in/u:rybesh/public/</link>
    <description>recent bookmarks from rybesh</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://rednegra.net/blog/20260212-virtual-scroll/"/>
	<rdf:li rdf:resource="https://graphorigami.org/"/>
	<rdf:li rdf:resource="https://simonwillison.net/2021/Jul/28/baked-data/"/>
	<rdf:li rdf:resource="http://aosabook.org/en/500L/web-spreadsheet.html"/>
	<rdf:li rdf:resource="https://martinfowler.com/articles/data-monolith-to-mesh.html"/>
	<rdf:li rdf:resource="https://bitworking.org/news/2019/07/looking-back-on-five-years-of-web-components"/>
	<rdf:li rdf:resource="https://cloud.google.com/apis/design/"/>
	<rdf:li rdf:resource="http://open-services.net/"/>
	<rdf:li rdf:resource="http://elm-lang.org/blog/farewell-to-frp"/>
	<rdf:li rdf:resource="http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome"/>
	<rdf:li rdf:resource="https://github.com/substack/omega-projects/issues/8"/>
	<rdf:li rdf:resource="http://www.infoworld.com/article/2880204/collaboration-software/wiki-creator-reinvents-collaboration-again.html"/>
	<rdf:li rdf:resource="https://github.com/TryGhost/Ghost/issues/2144"/>
	<rdf:li rdf:resource="http://dashes.com/anil/2012/12/the-web-we-lost.html"/>
	<rdf:li rdf:resource="http://www.theatlantic.com/technology/archive/2014/08/advertising-is-the-internets-original-sin/376041/"/>
	<rdf:li rdf:resource="http://www.wired.co.uk/news/archive/2014-02/06/tim-berners-lee-reclaim-the-web"/>
	<rdf:li rdf:resource="http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf"/>
	<rdf:li rdf:resource="http://onlinelibrary.wiley.com/doi/10.1002/bult.2013.1720390510/abstract"/>
	<rdf:li rdf:resource="http://tech.groups.yahoo.com/group/rest-discuss/message/19364"/>
	<rdf:li rdf:resource="http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons"/>
	<rdf:li rdf:resource="http://roy.gbiv.com/untangled/2008/economies-of-scale"/>
	<rdf:li rdf:resource="http://maxogden.com/replicating-large-datasets-into-html5"/>
	<rdf:li rdf:resource="http://en.wikipedia.org/wiki/Zachman_Framework"/>
	<rdf:li rdf:resource="http://www.lrec-conf.org/proceedings/lrec2010/pdf/507_Paper.pdf"/>
	<rdf:li rdf:resource="http://constructibl.es/"/>
	<rdf:li rdf:resource="http://blog.nodejitsu.com/scaling-isomorphic-javascript-code"/>
	<rdf:li rdf:resource="http://roca-style.org/"/>
	<rdf:li rdf:resource="http://joehewitt.com/2011/09/26/what-the-web-is-and-is-not"/>
	<rdf:li rdf:resource="http://tech.groups.yahoo.com/group/rest-discuss/message/18266"/>
	<rdf:li rdf:resource="http://www.w3.org/2001/tag/findings"/>
	<rdf:li rdf:resource="http://www.w3.org/TR/webarch/"/>
	<rdf:li rdf:resource="http://dret.net/netdret/docs/soa-rest-www2009/design.pdf"/>
	<rdf:li rdf:resource="http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf"/>
	<rdf:li rdf:resource="http://www.w3.org/DesignIssues/HTTP-URI2"/>
	<rdf:li rdf:resource="http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html"/>
	<rdf:li rdf:resource="http://www.w3.org/DesignIssues/HTTP-URI.html"/>
	<rdf:li rdf:resource="http://www.amundsen.com/blog/archives/1115"/>
	<rdf:li rdf:resource="http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm"/>
	<rdf:li rdf:resource="http://www.w3.org/2002/11/dbooth-names/dbooth-rfc2396-analysis_clean.htm"/>
	<rdf:li rdf:resource="https://github.com/interedition/microservices"/>
	<rdf:li rdf:resource="http://www.interedition.eu/wiki/index.php/About_microservices"/>
	<rdf:li rdf:resource="http://www.infoq.com/presentations/Hypermedia-Services-for-Systems-Integration"/>
	<rdf:li rdf:resource="http://rsms.me/2011/09/10/dropular-net-tech.html"/>
	<rdf:li rdf:resource="http://blogs.reuters.com/felix-salmon/2011/08/23/adventures-with-paywalls-ft-edition/"/>
	<rdf:li rdf:resource="http://code.google.com/p/implementing-rest/"/>
	<rdf:li rdf:resource="http://dret.net/lectures/ppos-spring11/"/>
	<rdf:li rdf:resource="http://www.oembed.com/"/>
	<rdf:li rdf:resource="http://pinktentacle.com/2010/08/post-apocalyptic-tokyo-scenery/"/>
	<rdf:li rdf:resource="http://factoryjoe.com/blog/2009/11/16/the-death-of-the-url/"/>
	<rdf:li rdf:resource="http://www.w3.org/DesignIssues/TermResource.html"/>
	<rdf:li rdf:resource="http://juxtaprose.com/posts/portable-clouds"/>
	<rdf:li rdf:resource="http://simonwillison.net/2009/Apr/11/revcanonical/"/>
	<rdf:li rdf:resource="http://revcanonical.appspot.com/"/>
	<rdf:li rdf:resource="http://www.w3.org/TR/2008/NOTE-cooluris-20081203/#r303gendocument"/>
	<rdf:li rdf:resource="https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Dec/0416.html"/>
	<rdf:li rdf:resource="http://slurl.com/about.php"/>
	<rdf:li rdf:resource="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven"/>
	<rdf:li rdf:resource="http://web.fumsi.com/go/article/manage/3126"/>
	<rdf:li rdf:resource="http://www.jstor.org/stable/2629118"/>
	<rdf:li rdf:resource="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2"/>
	<rdf:li rdf:resource="http://roy.gbiv.com/untangled/2008/on-software-architecture"/>
	<rdf:li rdf:resource="http://rubyforge.org/projects/conveyor/"/>
	<rdf:li rdf:resource="http://incubator.apache.org/uima/"/>
	<rdf:li rdf:resource="http://developers.facebook.com/thrift/"/>
	<rdf:li rdf:resource="http://www.cmlenz.net/archives/2007/10/couchdb-joins"/>
	<rdf:li rdf:resource="http://www.freebase.com/view/guid/9202a8c04000641f8000000003e0318a"/>
	<rdf:li rdf:resource="http://dannyayers.com/2007/11/14/hash-soup"/>
	<rdf:li rdf:resource="http://purl.org/"/>
	<rdf:li rdf:resource="http://mjtemplate.org/examples/rison.html"/>
	<rdf:li rdf:resource="http://danbri.org/words/2007/09/13/194"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://rednegra.net/blog/20260212-virtual-scroll/">
    <title>Virtual Scrolling for Billions of Rows — Techniques from HighTable</title>
    <dc:date>2026-02-17T22:12:17+00:00</dc:date>
    <link>https://rednegra.net/blog/20260212-virtual-scroll/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[No need for a fake scroll bar. No need to render the table in a canvas. We use the Web platform. Thanks to these five techniques that rely on native HTML elements, hightable lets you navigate seamlessly through billions of rows of a remote data file, in the browser.]]></description>
<dc:subject>html css web design architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:cf9777ba300f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://graphorigami.org/">
    <title>Web Origami</title>
    <dc:date>2023-11-28T02:03:35+00:00</dc:date>
    <link>https://graphorigami.org/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Web Origami is a research project exploring ideas and tools for building a wide variety of software artifacts and digital content. The system encourages you to view creating such things as an exercise in transformation: you take your starting files, data, etc., and transform them step-by-step into a final result you can use and share.

]]></description>
<dc:subject>web architecture ideas</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:769cbee5436e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:ideas"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://simonwillison.net/2021/Jul/28/baked-data/">
    <title>The Baked Data architectural pattern</title>
    <dc:date>2022-11-15T19:21:54+00:00</dc:date>
    <link>https://simonwillison.net/2021/Jul/28/baked-data/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Baked Data: bundling a read-only copy of your data alongside the code for your application, as part of the same deployment.]]></description>
<dc:subject>data publishing architecture patterns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:a311d5e1da16/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:publishing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:patterns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://aosabook.org/en/500L/web-spreadsheet.html">
    <title>500 Lines or Less | Web Spreadsheet</title>
    <dc:date>2021-11-17T22:49:32+00:00</dc:date>
    <link>http://aosabook.org/en/500L/web-spreadsheet.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[This chapter introduces a web spreadsheet written in 99 lines of the three languages natively supported by web browsers: HTML, JavaScript, and CSS.]]></description>
<dc:subject>javascript architecture spreadsheet css html</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:6baf87049cca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:spreadsheet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:html"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://martinfowler.com/articles/data-monolith-to-mesh.html">
    <title>How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh</title>
    <dc:date>2021-01-06T01:39:06+00:00</dc:date>
    <link>https://martinfowler.com/articles/data-monolith-to-mesh.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Many enterprises are investing in their next generation data lake, with the hope of democratizing data at scale to provide business insights and ultimately make automated intelligent decisions. Data platforms based on the data lake architecture have common failure modes that lead to unfulfilled promises at scale. To address these failure modes we need to shift from the centralized paradigm of a lake, or its predecessor data warehouse. We need to shift to a paradigm that draws from modern distributed architecture: considering domains as the first class concern, applying platform thinking to create self-serve data infrastructure, and treating data as a product.]]></description>
<dc:subject>distributed data architecture design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:fb0f7990f392/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bitworking.org/news/2019/07/looking-back-on-five-years-of-web-components">
    <title>Looking back on five years of web components</title>
    <dc:date>2019-08-01T08:20:41+00:00</dc:date>
    <link>https://bitworking.org/news/2019/07/looking-back-on-five-years-of-web-components</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[“A la carte” web development does away with the framework, and says just use the browser for the model, and the rest of the pieces you pick and choose the ones that work for you.]]></description>
<dc:subject>web development architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:b47501701ada/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloud.google.com/apis/design/">
    <title>API Design Guide  |  Cloud APIs  |  Google Cloud Platform</title>
    <dc:date>2017-03-05T15:43:26+00:00</dc:date>
    <link>https://cloud.google.com/apis/design/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide we follow when designing Cloud APIs and other Google APIs. It is shared here to inform outside developers and to make it easier for us all to work together.

External developers may find it particularly useful when designing gRPC APIs for use with Google Cloud Endpoints, and we strongly recommend such developers use these design principles. However, we don't mandate its use for any non-Google developer and you can use Cloud Endpoints and/or gRPC without following the guide.

This guide applies to both REST APIs and RPC APIs, with specific focus on gRPC APIs. gRPC APIs use Protocol Buffers to define their API surface and API Service Configuration to configure their API services, including HTTP mapping, logging, and monitoring. HTTP mapping features are used by Google APIs and gRPC Cloud Endpoints APIs for JSON/HTTP to Protocol Buffers/RPC transcoding.

This guide is a living document and additions to it will be made over time as new style and design patterns are adopted and approved. In that spirit, it is never going to be complete and there will always be ample room for the art and craft of API design.]]></description>
<dc:subject>api design documentation architecture inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:cfdd0c9895bd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://open-services.net/">
    <title>Open Services for Lifecycle Collaboration</title>
    <dc:date>2016-11-22T18:33:51+00:00</dc:date>
    <link>http://open-services.net/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[OSLC (Open Services for Lifecycle Collaboration) is an open and extensible framework that accelerates innovation by removing integration bottlenecks between all the disparate applications that contribute to the entire product lifecycle. OSLC replaces highly coupled, proprietary, server-to-server replication integrations with uncoupled, standards-based, “write once integrate everywhere” solutions. Building on WWW standards to define a minimal set of capabilities that support the most common integration scenarios, OSLC defines an approach for resource and capability discovery and UI enablement.]]></description>
<dc:subject>linkeddata architecture webservices standards inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:1db3ddcb328a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:linkeddata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:webservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://elm-lang.org/blog/farewell-to-frp">
    <title>farewell-to-frp</title>
    <dc:date>2016-05-16T17:49:23+00:00</dc:date>
    <link>http://elm-lang.org/blog/farewell-to-frp</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Subscriptions let components sit around and wait for messages while library code handles a bunch of tricky resource management stuff behind the scenes.]]></description>
<dc:subject>elm architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:c2df84cb90f8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:elm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome">
    <title>Removing User Interface Complexity, or Why React is Awesome</title>
    <dc:date>2015-06-17T03:09:09+00:00</dc:date>
    <link>http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[I ask that you set aside your framework prejudices and read this post with an open mind. This post is not to evangelize React specifically, but to explain why its technique is profound. I want developers steeped in other technologies to take a hard look at these techniques, particularly those involved in Web Components.]]></description>
<dc:subject>javascript programming react architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:7b7bd7cd07de/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:react"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/substack/omega-projects/issues/8">
    <title>decentralized authentication · Issue #8 · substack/omega-projects</title>
    <dc:date>2015-06-05T13:11:09+00:00</dc:date>
    <link>https://github.com/substack/omega-projects/issues/8</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[A decentralized solution to authentication needs many pieces to succeed and many of those pieces are social in nature. Several of these pieces may turn out to be dual-sided, which will make them more difficult to gain adoption but may protect their position once properly established.]]></description>
<dc:subject>authentication decentralize web architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:ebd4e2f0e7d8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:authentication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:decentralize"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoworld.com/article/2880204/collaboration-software/wiki-creator-reinvents-collaboration-again.html">
    <title>Wiki creator reinvents collaboration, again | InfoWorld</title>
    <dc:date>2015-02-16T14:01:29+00:00</dc:date>
    <link>http://www.infoworld.com/article/2880204/collaboration-software/wiki-creator-reinvents-collaboration-again.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[This new wiki is composed of a server and a client written in CoffeeScript. The server is a minimal persistence engine that's designed for scenarios ranging from laboratory control systems to academic server farms. The pages it stores contain only JSON, rendered by the client, which does most of the work. Two JSON objects comprise a page: the story (a set of items) and the journal (which remembers how items were added, edited, moved, or deleted). You add items to the page by means of plug-ins that inject paragraphs of plain text, HTML, or markdown, as well as images, video, equations, raw data, charts, and computations. 

The browser displays multiple pages arranged as a horizontal lineup that may include a mixture of pages from your server and pages from other servers. The lineup can be a composable pipeline for data. I can load a URL from your site that flows a data set from one page into a chart on the next, then fork your page of data, change it, and compare the two charts. Every time I edit my copy of the data set, the journal records a new version. If somebody else forks my page, she'll have the whole history: your original data set, your changes, the version I forked, and my changes. 

The federation as a whole includes all the servers running this software. But as a user of an individual server I am part of a "neighborhood" that forms dynamically as I navigate to remote pages, visit pages with special references to pages elsewhere in the federation, or load pages that were forked from elsewhere in the federation. The neighborhood defines the scope for search and for resolution of links by page name rather than by fully qualified URL. ]]></description>
<dc:subject>wiki collaboration architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:70a3eb5a5f58/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:wiki"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:collaboration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/TryGhost/Ghost/issues/2144">
    <title>[Discussion] The future of Ghost's admin UI · Issue #2144 · TryGhost/Ghost</title>
    <dc:date>2014-12-11T18:56:17+00:00</dc:date>
    <link>https://github.com/TryGhost/Ghost/issues/2144</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Discussion point 2: What is the best structure for a complex client side app like this?

This sort of depends on the tool used to build it, but also has implications for choosing a tool.

Is the Ghost admin a single page app, or a collection of single page apps? If you take the dashboard into consideration, I believe that alone is a single page app. The editor is probably the same.

Do you have ideas on how to structure the admin UI, and how to ensure it works as a whole?

Discussion point 3: Is backbone the best framework for the job?

There are many other potential tools we could use, and there are a few main solutions that we consider to be on the table:

Improving the current backbonejs implementation by adding more underlying structure and using additional tools like marionette and rendr
Switching to emberjs
Switching to angular
Something else entirely?]]></description>
<dc:subject>javascript framework web browser client architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:d87460816006/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:client"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dashes.com/anil/2012/12/the-web-we-lost.html">
    <title>The Web We Lost - Anil Dash</title>
    <dc:date>2014-08-23T14:03:19+00:00</dc:date>
    <link>http://dashes.com/anil/2012/12/the-web-we-lost.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[We've lost key features that we used to rely on, and worse, we've abandoned core values that used to be fundamental to the web world.]]></description>
<dc:subject>web architecture culture critique</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:380216f3fb54/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:critique"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.theatlantic.com/technology/archive/2014/08/advertising-is-the-internets-original-sin/376041/">
    <title>The Internet's Original Sin - The Atlantic</title>
    <dc:date>2014-08-23T14:01:25+00:00</dc:date>
    <link>http://www.theatlantic.com/technology/archive/2014/08/advertising-is-the-internets-original-sin/376041/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[What we wanted to do was to build a tool that made it easy for everyone, everywhere to share knowledge, opinions, ideas and photos of cute cats. As everyone knows, we had some problems, primarily business model problems, that prevented us from doing what we wanted to do the way we hoped to do it. What we’re asking for today is a conversation about how we could do this better, since we screwed up pretty badly the first time around.]]></description>
<dc:subject>web architecture privacy critique</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:328c89b1e94c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:critique"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.wired.co.uk/news/archive/2014-02/06/tim-berners-lee-reclaim-the-web">
    <title>Tim Berners-Lee: we need to re-decentralise the web (Wired UK)</title>
    <dc:date>2014-08-23T14:00:51+00:00</dc:date>
    <link>http://www.wired.co.uk/news/archive/2014-02/06/tim-berners-lee-reclaim-the-web</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Twenty-five years on from the web's inception, its creator has urged the public to re-engage with its original design: a decentralised internet that at its very core, remains open to all.]]></description>
<dc:subject>web architecture decentralize</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:177edbdc2ede/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:decentralize"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf">
    <title>Tussle in Cyberspace: Deﬁning Tomorrow’s Internet</title>
    <dc:date>2014-01-04T17:52:04+00:00</dc:date>
    <link>http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The architecture of the Internet is based on a number of principles, including the self-describing datagram packet, the end-to-end arguments, diversity in technology and global addressing. As the Internet has moved from a research curiosity to a recognized component of mainstream society, new requirements have emerged that suggest new design principles, and perhaps suggest that we revisit some old ones. This paper explores one important reality that surrounds the Internet today: different stakeholders that are part of the Internet milieu have interests that may be adverse to each other, and these parties each vie to favor their particular interests. We call this process “the tussle.” Our position is that accommodating this tussle is crucial to the evolution of the network’s technical architecture. We discuss some examples of tussle, and offer some technical design principles that take it into account.]]></description>
<dc:subject>internet architecture standards economics politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:efbeeb955212/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:economics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://onlinelibrary.wiley.com/doi/10.1002/bult.2013.1720390510/abstract">
    <title>Transforming our conversation of information architecture with structure - Davis - 2013 - Bulletin of the American Society for Information Science and Technology - Wiley Online Library</title>
    <dc:date>2013-06-24T16:56:45+00:00</dc:date>
    <link>http://onlinelibrary.wiley.com/doi/10.1002/bult.2013.1720390510/abstract</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Since the origin of the concept, information architecture has been viewed as an art and a science, rooted in library science but borrowing from multiple disciplines. Though there are recognized elements, some say it lacks a foundation of consistent internal theory. The central concept of information architecture is structure. Though invisible and often taken for granted, effective structure is the quality that makes websites functional. It rests on navigation, information organization and information relationships and can extend to user experience and spatial representation. Information architecture reflects elements from a number of disciplines but, by aggregating them, is greater than the parts. Advancing information architecture from art to science depends on shared strategies and solutions for website structure.]]></description>
<dc:subject>inls520 structure information architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:9cc14b38e28b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls520"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:structure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:information"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.groups.yahoo.com/group/rest-discuss/message/19364">
    <title>rest-discuss : Message: RE: [rest-discuss] the meaning of stateless</title>
    <dc:date>2013-04-26T13:11:25+00:00</dc:date>
    <link>http://tech.groups.yahoo.com/group/rest-discuss/message/19364</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Lots of web developers think an "application" is "the code I wrote in Python or
Ruby that runs on the server." But that is worlds apart from the way Roy uses
it. He uses it in its original sense of "accomplishing a goal with something".]]></description>
<dc:subject>rest architecture inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:882528056518/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons">
    <title>Paper tigers and hidden dragons » Untangled</title>
    <dc:date>2013-04-08T14:44:20+00:00</dc:date>
    <link>http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Web architects must understand that resources are just consistent mappings from an identifier to some set of views on server-side state. If one view doesn’t suit your needs, then feel free to create a different resource that provides a better view (for any definition of “better”). These views need not have anything to do with how the information is stored on the server, or even what kind of state it ultimately reflects. It just needs to be understandable (and actionable) by the recipient.

In this case, we want to represent the last-updated state of all Flickr users in a way that minimizes the lag between event and notification (let’s just assume that one minute is “fast enough” to receive a change notification). The simplest way of doing that is to log state changes by userid in a sequence of journal-style resources named according to the server’s UTC clock minutes.]]></description>
<dc:subject>rest updates architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:fe9076696d3c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:updates"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://roy.gbiv.com/untangled/2008/economies-of-scale">
    <title>Economies of scale » Untangled</title>
    <dc:date>2013-04-08T14:37:26+00:00</dc:date>
    <link>http://roy.gbiv.com/untangled/2008/economies-of-scale</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Event-based integration (EBI) is a natural fit for systems that monitor real-time activities, particularly when the number of event sources outnumber the recipients of event notifications (e.g, graphical user interfaces and process control systems). However, EBI does not scale well when the number of recipients greatly outnumbers the sources.]]></description>
<dc:subject>web architecture economics pubsub REST</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:77b27ce4d88f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:economics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:pubsub"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:REST"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://maxogden.com/replicating-large-datasets-into-html5">
    <title>Max Ogden Blogotronz</title>
    <dc:date>2012-08-05T21:14:59+00:00</dc:date>
    <link>http://maxogden.com/replicating-large-datasets-into-html5</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The time for fat clients is now! There are some key projects that were all released over the last month or two that allow for some really exciting (relatively) large data manipulation and storage in the browser. If you Voltron them together you can open up an AJAX request to arbitrarily large JSON response that you can stream in realtime into a persistent client-side data store. This workflow opens up a lot of new web application possibilities.]]></description>
<dc:subject>javascript data analysis architecture html</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:542d3c35b0f9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:html"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://en.wikipedia.org/wiki/Zachman_Framework">
    <title>Zachman Framework - Wikipedia, the free encyclopedia</title>
    <dc:date>2012-07-02T17:15:43+00:00</dc:date>
    <link>http://en.wikipedia.org/wiki/Zachman_Framework</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The basic idea behind the Zachman Framework is that the same complex thing or item can be described for different purposes in different ways using different types of descriptions (e.g., textual, graphical). The Zachman Framework provides the thirty-six necessary categories for completely describing anything; especially complex things like manufactured goods (e.g., appliances), constructed structures (e.g., buildings), and enterprises (e.g., the organization and all of its goals, people, and technologies). The framework provides six different transformations of an abstract idea (not increasing in detail, but transforming) from six different perspectives.]]></description>
<dc:subject>description framework models information architecture inls520</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:3aba1dfc4ed0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:description"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:models"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:information"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls520"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.lrec-conf.org/proceedings/lrec2010/pdf/507_Paper.pdf">
    <title>Computational Linguistics for Mere Mortals</title>
    <dc:date>2012-06-28T20:01:50+00:00</dc:date>
    <link>http://www.lrec-conf.org/proceedings/lrec2010/pdf/507_Paper.pdf</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Delivering linguistic resources and easy-to-use methods to a broad public in the humanities is a challenging task. On the one hand users rightly demand easy to use interfaces but on the other hand want to have access to the full flexibility and power of the functions being offered. Even though a growing number of excellent systems exist which offer convenient means to use linguistic resources and methods, they usually focus on a specific domain, as for example corpus exploration or text categorization. Architectures which address a broad scope of applications are still rare. This article introduces the eHumanities Desktop, an online system for corpus management, processing and analysis which aims at bridging the gap between powerful command line tools and intuitive user interfaces.]]></description>
<dc:subject>digitalhumanities corpus linguistics nlp architecture tools</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:dc855b433048/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:digitalhumanities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:corpus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:linguistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:nlp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:tools"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://constructibl.es/">
    <title>Constructibles</title>
    <dc:date>2012-06-18T22:08:57+00:00</dc:date>
    <link>http://constructibl.es/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[A constructible HTML page is your everday HTML page with a twist; it adds a few extra meta tags as well as a few special attributes to a group of div tags that each map to a discrete part.

To the developers, these additions make highly dynamic and interactive HTML pages simpler to test, maintain, extend, and reuse. To the others, they make an otherwise complex mixture of advanced technologies such as Ajax, DOM, Javascript, etc.., more tweakable, and repurposable.

A Javascript part is Javascript that has been cleanly packaged, such that it can be tweaked, and repurposed by anyone who has knowledge of HTML.

Packaging your javascript as a part makes it not only simpler to test, maintain, replace, extend, and reuse, but also usable. Usable not only by other developers, but also by those who do not know Javascript!]]></description>
<dc:subject>html javascript architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:3fce31b4a07b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.nodejitsu.com/scaling-isomorphic-javascript-code">
    <title>Scaling Isomorphic Javascript Codeblog.nodejitsu.com - scaling node.js applications one callback at a time.</title>
    <dc:date>2012-04-26T13:32:51+00:00</dc:date>
    <link>http://blog.nodejitsu.com/scaling-isomorphic-javascript-code</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Javascript is now an isomorphic language. By isomorphic we mean that any given line of code (with notable exceptions) can execute both on the client and the server. On the surface this seemingly innocuous property creates a number of challenges that are not solved by current MVC-based patterns. This article will explore some of these existing patterns, how both their implementation and concerns vary across languages and environments, and how they are not good enough for a truly isomorphic Javascript codebase. In conclusion, we will explore a new pattern: Resource-View-Presenter. ]]></description>
<dc:subject>javascript architecture nodejs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:2f9e4f733a9b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:nodejs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://roca-style.org/">
    <title>ROCA: Resource-oriented Client Architecture</title>
    <dc:date>2012-03-11T00:58:46+00:00</dc:date>
    <link>http://roca-style.org/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[ROCA is an attempt to define a set of recommendations — independent of any particular framework, programming language, or tooling — that embodies the principles of what we consider to be good web application architecture. Its purpose is to serve as a reference, one that can be implemented as-is or be compared to other approaches to highlight diverging design decisions.]]></description>
<dc:subject>web architecture rest inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:f2fc58bc841f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://joehewitt.com/2011/09/26/what-the-web-is-and-is-not">
    <title>What the Web is and is not - Joe Hewitt</title>
    <dc:date>2012-01-02T18:27:54+00:00</dc:date>
    <link>http://joehewitt.com/2011/09/26/what-the-web-is-and-is-not</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[I'm beginning to see that some parts of the Web we take for granted are not what actually defines it. The Web is not HTML, CSS, and JavaScript. It's not DOM, SVG, WebGL, PNG, or Flash. The Web is really just HTTP over TCP/IP. What gets transported over HTTP does not define the Web.

There is, however, one other characteristic that does define the Web, and that is the humble hyperlink. Links are a feature of HTML, but they are not limited to HTML. Links are the connections that give the Web its name, and links are the biggest thing missing from native platforms.

My definition of the Web then is resources loaded over the Internet using HTTP and then displayed in a hyperlink-capable client.]]></description>
<dc:subject>web architecture inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:b73f37d0cb7a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.groups.yahoo.com/group/rest-discuss/message/18266">
    <title>rest-discuss : Message: Re: [rest-discuss] Re: The &quot;new media types are evil&quot; meme</title>
    <dc:date>2011-12-31T02:07:23+00:00</dc:date>
    <link>http://tech.groups.yahoo.com/group/rest-discuss/message/18266</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[1 - Find the set of architecture properties of key interest[1]
2 - Formulate an active approach to defining our an architecture that
induces these properties[2]
3 - Then, using the collective knowledge of already existing styles [3]
4 - Develop a style that meets the needs of the identified problem domain

This process is the actual topic of Fielding's dissertation. "REST" is
just his example "step 4" from above.]]></description>
<dc:subject>web architecture design rest inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:7aec20da0ba5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/2001/tag/findings">
    <title>Findings of the W3C Technical Architecture Group (TAG)</title>
    <dc:date>2011-12-30T18:46:51+00:00</dc:date>
    <link>http://www.w3.org/2001/tag/findings</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The primary activity of the TAG is to develop Architectural Recommendations. The TAG findings listed below document fundamental principles that should be adhered to by all Web components. The TAG expects to include these findings in the TAG's Architectural Recommendations, to be published according to the requirements of the W3C Recommendation Track process.]]></description>
<dc:subject>web architecture reference inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:f8e605ccfb65/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/TR/webarch/">
    <title>Architecture of the World Wide Web, Volume One</title>
    <dc:date>2011-12-30T18:46:07+00:00</dc:date>
    <link>http://www.w3.org/TR/webarch/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space. We relate core design components, constraints, and good practices to the principles and properties they support.]]></description>
<dc:subject>architecture http rest web inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:c19a88bfa4e8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dret.net/netdret/docs/soa-rest-www2009/design.pdf">
    <title>RESTful Service Design</title>
    <dc:date>2011-12-30T18:30:23+00:00</dc:date>
    <link>http://dret.net/netdret/docs/soa-rest-www2009/design.pdf</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Presentation from Cesare Pautasso and Erik Wilde.]]></description>
<dc:subject>rest web architecture design inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:9bdc5673ac7d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf">
    <title>In Defense of Ambiguity</title>
    <dc:date>2011-12-30T15:41:51+00:00</dc:date>
    <link>http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[• There are two distinct relationships between names and things.  Reference is different from access. The architecture of the Web determines access, but has no direct influence on reference
• Reference can be established by ostention or by description.  Description is inherently ambiguous; ostention can be done only to accessible entities.
• Therefore, references to non-accessible entities - the vast majority of references - must be by description, and hence must be ambiguous.
• Reference to accessible entities still differs from access.  Establishing reference by ostention requires naming conventions. Access is one form of ostention.]]></description>
<dc:subject>identifiers naming web architecture uri inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:67ba32752956/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identifiers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:naming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/DesignIssues/HTTP-URI2">
    <title>What do HTTP URIs Identify? - Design Issues</title>
    <dc:date>2011-12-30T15:37:26+00:00</dc:date>
    <link>http://www.w3.org/DesignIssues/HTTP-URI2</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[HTTP URIs, in the web architecture, have been used to denote documents -- "web pages" informally, or "information resources" more formally. However, with the growth of the Semantic Web, which uses URIs to denote anything at all, the urge to use and practice of using HTTP URIs for arbitrary things grew steadily. The W3C Technical Architecture group eventually decided to resolve the architectural problem that if an HTTP response code of 200 (a successful retrieval) was given, that indicated that the URI indeed was for an information resource, but with no such response, or with a different code, no such assumption could be made. This compromise resolved the issue, leaving a consistent architecture.]]></description>
<dc:subject>web architecture identifiers uri inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:f707eb390a16/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identifiers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html">
    <title>[httpRange-14] Resolved from Roy T. Fielding on 2005-06-19 (www-tag@w3.org from June 2005)</title>
    <dc:date>2011-12-30T15:36:42+00:00</dc:date>
    <link>http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[I believe that this solution enables people to name arbitrary
resources using the "http" namespace without any dependence on
fragment vs non-fragment URIs, while at the same time providing
a mechanism whereby information can be supplied via the 303
redirect without leading to ambiguous interpretation of such
information as being a representation of the resource (rather,
the redirection points to a different resource in the same way
as an external link from one resource to the other).]]></description>
<dc:subject>http identifiers uri web architecture inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:8417f7fcf50c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identifiers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/DesignIssues/HTTP-URI.html">
    <title>What do HTTP URIs Identify? - Design Issues</title>
    <dc:date>2011-12-30T15:35:44+00:00</dc:date>
    <link>http://www.w3.org/DesignIssues/HTTP-URI.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[I didn't have this thought out a few years ago. It has only been in actually building a relatively formal system on top of the web infrastructure that I have had to clarify these concepts my own mind. I am forced to conclude that modeling the HTTP part of the web as a web of abstract documents if the only way to go which is practical and, by the philosophical underpinnings of the WWW, tenable.]]></description>
<dc:subject>web architecture identifiers uri inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:f314eb141b43/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identifiers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.amundsen.com/blog/archives/1115">
    <title>mca blog [REST : 'inverted' architecture]</title>
    <dc:date>2011-12-30T15:30:39+00:00</dc:date>
    <link>http://www.amundsen.com/blog/archives/1115</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[history has shown that the HTTP protocol is a very flexible protocol and that not all implementations need to follow the example provided by Fielding in order to meet the needs of users. for example, RPC over HTTP works just fine for many cases; esp. those that do not require system stability on the scale of years/decades.

however, the more important it is for the solution to continue to operate (and evolve) over an extended period of time, the more useful are the additional constraints Fielding identified in his example and the more important it is to optimize for run-time stability over ease/speed of initial implementation.]]></description>
<dc:subject>rest http web architecture inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:cc65f856daea/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm">
    <title>Names, Documents and Concepts</title>
    <dc:date>2011-12-30T15:05:47+00:00</dc:date>
    <link>http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[URLs can be used to identify abstract concepts or other things that do not exist directly on the Web.  This is sensible, but it means that the same URL might be used in conjunction with four different (but related) things: a name, a concept, a Web location or a document instance.  Somehow, we need conventions for denoting these four different uses.  Two approaches are available: different names or different context.  The "different names" approach requires new URI schemes or conventions; the "different context" approach requires syntactic conventions for indicating the intended context.]]></description>
<dc:subject>identifiers uri web architecture standards inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:4f6c0f05d2f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identifiers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/2002/11/dbooth-names/dbooth-rfc2396-analysis_clean.htm">
    <title>What Part of &quot;Resource&quot; Don't I Understand?</title>
    <dc:date>2011-12-30T15:05:03+00:00</dc:date>
    <link>http://www.w3.org/2002/11/dbooth-names/dbooth-rfc2396-analysis_clean.htm</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[This document analyzes the definition of "resource" in RFC2396 [1] in an attempt to understand it.  It notes ten questions or points of confusion (labeled QUESTION1 - QUESTION10) that I encountered.
 
WARNING: This analysis is painfully detailed, and somewhat rambling (sorry!), reflecting my thought process as I (honestly) attempted to understand the definition.  It is only recommended to those who believe that the definition is clear, and want to see evidence to the contrary.]]></description>
<dc:subject>uri web architecture standards inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:c71aa5e4f874/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/interedition/microservices">
    <title>interedition/microservices - GitHub</title>
    <dc:date>2011-11-29T11:52:24+00:00</dc:date>
    <link>https://github.com/interedition/microservices</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Microservices developed by a European-funded development collective whose aim it is to promote the interoperability of the tools and methodology we use in the field of digital scholarly editing and research.]]></description>
<dc:subject>rest webservices architecture digitalhumanities dh</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:0295c2fc6a06/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:webservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:digitalhumanities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:dh"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.interedition.eu/wiki/index.php/About_microservices">
    <title>About microservices - IntereditionWiki</title>
    <dc:date>2011-11-29T11:50:05+00:00</dc:date>
    <link>http://www.interedition.eu/wiki/index.php/About_microservices</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Micro services are small cloud deployed web services supporting specific tasks in (any) digital work flow pertaining to larger scholarly tasks. They are the small reusable web published building blocks of digital scholarly tools. They provide the basic solution to interoperability and sustainability for digital scholarly tools Interedition is striving for.]]></description>
<dc:subject>webservices rest architecture digitalhumanities dh</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:5bab34826c01/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:webservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:digitalhumanities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:dh"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/presentations/Hypermedia-Services-for-Systems-Integration">
    <title>InfoQ: Using Hypermedia Services for Systems Integration</title>
    <dc:date>2011-09-30T18:41:20+00:00</dc:date>
    <link>http://www.infoq.com/presentations/Hypermedia-Services-for-Systems-Integration</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Tim Ewald explains why hypermedia is good for system integration through services –providing support for evolution, service request routing, and application recovery-, and how to build such services. ]]></description>
<dc:subject>architecture hypermedia rest inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:ff176e2e6517/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:hypermedia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rsms.me/2011/09/10/dropular-net-tech.html">
    <title>Designing a modern web-based application — Dropular.net — Rasmus Andersson</title>
    <dc:date>2011-09-12T16:14:46+00:00</dc:date>
    <link>http://rsms.me/2011/09/10/dropular-net-tech.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Oui is a kit and framework for building larger websites, in the same fashion as networked and distributed desktop applications.

All code is modern JavaScript -- Node.js for the server and in the browser at the client side.
The user interface is completely handled client-side
Client-server communication is REST-ful and exchange structured data (JSON)
All JavaScript, HTML and CSS is namespaced (derived from file structure)]]></description>
<dc:subject>web javascript ajax design architecture html</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:1f7c398aa47d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:ajax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:html"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blogs.reuters.com/felix-salmon/2011/08/23/adventures-with-paywalls-ft-edition/">
    <title>Adventures with paywalls, FT edition | Felix Salmon</title>
    <dc:date>2011-08-24T21:46:39+00:00</dc:date>
    <link>http://blogs.reuters.com/felix-salmon/2011/08/23/adventures-with-paywalls-ft-edition/</link>
    <dc:creator>rybesh</dc:creator><dc:subject>web architecture linking</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:30a40939582c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:linking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://code.google.com/p/implementing-rest/">
    <title>implementing-rest - Exploring the implementation aspects of the REST architectural style. - Google Project Hosting</title>
    <dc:date>2011-05-11T12:45:35+00:00</dc:date>
    <link>http://code.google.com/p/implementing-rest/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[This is a place for exploring aspects of implementing applications using the REST architectural style. This may include statements about existing frameworks and libraries, general discussions about the nature of the style and how it may be expressed and/or encouraged via a programming framework, etc.]]></description>
<dc:subject>rest architecture api</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:7da5ea4fcdcc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:api"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dret.net/lectures/ppos-spring11/">
    <title>Principles and Patterns of Organizing Systems (Spring 2011 — INFO 290-6 — CCN 42628)</title>
    <dc:date>2011-01-30T00:55:04+00:00</dc:date>
    <link>http://dret.net/lectures/ppos-spring11/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[We have traditionally analyzed collections of information or things using categories like libraries, museums, archives, content or knowledge management systems, and data repositories. The concept of an organizing system complements this categorical view with a dimensional perspective that sees these categories as sets of design patterns that reflect typical answers to questions about what is being organized, why, when, how much, who is doing the organizing, and how services are provided to interact with the organizing system. These dimensions frame trade-offs and constraints about the content, policies, and implementation of organizing systems. The primary goal of this course is to use these design dimensions to better understand traditional design patterns and their consequences, and to identify useful new ones.

For example, the thingness, uniqueness, persistence, useful lifetime, mashability, and intended uses and users of the content of an organizing system jointly determine how it is implemented and operated. We will examine how these design influences intersect, and consider what alternative designs would look like if some of these content and policy choices were to change. Furthermore, in many domains the Web has become the default implementation of organizing systems interfaces, yet we don't critically examine the implications this should have on the system itself. So we will study how Web Architecture — or the architectures and constraints implied by other metamodels and architectures such as Linked Data or WS-* services — influence decisions about content granularity and structure, how identity and provenance are supported, the kinds of interactions and services the organizing system allows, and so on.]]></description>
<dc:subject>syllabus information organization web architecture inls620</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:614c3b2df00f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:syllabus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:information"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:organization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.oembed.com/">
    <title>oEmbed</title>
    <dc:date>2010-09-17T19:39:05+00:00</dc:date>
    <link>http://www.oembed.com/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.]]></description>
<dc:subject>transclusion web architecture standards api widget</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:rybesh/b:ed798e19f996/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:transclusion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:widget"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://pinktentacle.com/2010/08/post-apocalyptic-tokyo-scenery/">
    <title>Post-apocalyptic Tokyo scenery</title>
    <dc:date>2010-08-19T07:25:55+00:00</dc:date>
    <link>http://pinktentacle.com/2010/08/post-apocalyptic-tokyo-scenery/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The illustrations of TokyoGenso (a.k.a. Tokyo Fantasy) depict a post-apocalyptic Tokyo devoid of people and overtaken by nature. 

Shinjuku skyline [+]

Tokyo Big Sight [+]

Rainbow Bridge [+]

Moai statue at Shibuya station [+]

Kabuki-za Theater, Ginza [+]

Mode HAL iKO Building, Shinjuku [+]

Poster for "The Book of Eli" (Japanese title: "The Walker") [+]

 Gundam // Tokyogenso Robot

Tokyo Sky Tree [+]

Sofmap Akihabara [+]

Haneda Airport [+]

Cover of Liberal Time, September 2010

Akihabara [+]

Saigō Takamori statue, Ueno

Poster for "The Book of Eli" (a.k.a. "The Walker) - Osaka version [+]

Osaka street scene - Tsūtenkaku Tower  [+]

Osaka street scene - Billiken [+]

Osaka street scene [+]

Hato Bus [+]

Tokyo Monorail [+]

 Shibuya station (Fukutoshin Line) // Seibu Shibuya

"Manneken Pis" statue at Hamamatsuchō station

Ueno [+]

Tokyo Tower [+]

Shinjuku station [+]

Hanayashiki amusement park, Asakusa [+]

McDonald's [+]

Yoyogi station [+]

Nakano station [+]

Akihabara [+]

Shibuya [+]

Wako Building, Ginza [+]

[Links: tokyogenso blog, pixiv, deviantART]



 
]]></description>
<dc:subject>Art/Culture Architecture Art Landscape Tokyo Vegetation</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:baceee8883f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:Art/Culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:Architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:Art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:Landscape"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:Tokyo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:Vegetation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://factoryjoe.com/blog/2009/11/16/the-death-of-the-url/">
    <title>The death of the URL | FactoryCity</title>
    <dc:date>2009-11-19T00:37:02+00:00</dc:date>
    <link>http://factoryjoe.com/blog/2009/11/16/the-death-of-the-url/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[I see signs that the essential freedoms of the web are being undermined by a cadre of companies through the introduction of new technologies and interfaces that, combined, may spell the death of the URL.
]]></description>
<dc:subject>web architecture trends interface uri</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:6dcc86421249/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:trends"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:interface"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/DesignIssues/TermResource.html">
    <title>A Short History of &quot;Resource&quot; - Design Issues</title>
    <dc:date>2009-09-11T16:24:27+00:00</dc:date>
    <link>http://www.w3.org/DesignIssues/TermResource.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[There has been a lot of confusion from a wide varying uses use of this term for various different historical reasons, leading to uses which are sometimes ambiguous and in places inconsistent. This article attempts to shed light on the issue.
]]></description>
<dc:subject>web architecture naming history design inls620</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:a1e291d914d6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:naming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://juxtaprose.com/posts/portable-clouds">
    <title>Juxtaprose - Portable clouds</title>
    <dc:date>2009-08-14T00:53:46+00:00</dc:date>
    <link>http://juxtaprose.com/posts/portable-clouds</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[“Portable clouds” is a name for the idea that the “cloud” of the Internet is / can be made portable by copying portions of it onto your local networks, desktops and portable devices. Another way to say this is: really great replication and caching of the web.
]]></description>
<dc:subject>web architecture cache ideas documents</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:6b1804d1455d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:ideas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:documents"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://simonwillison.net/2009/Apr/11/revcanonical/">
    <title>rev=canonical bookmarklet and designing shorter URLs</title>
    <dc:date>2009-04-11T18:16:08+00:00</dc:date>
    <link>http://simonwillison.net/2009/Apr/11/revcanonical/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Implementing rev=canonical short URLs in Django.
]]></description>
<dc:subject>python django web architecture linking howto</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:38cbbe354901/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:django"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:linking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:howto"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://revcanonical.appspot.com/">
    <title>rev=canonical: url shortening that doesn't hurt the internet</title>
    <dc:date>2009-04-11T18:11:55+00:00</dc:date>
    <link>http://revcanonical.appspot.com/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[RevCanonical is url shortening with a twist. Instead of creating its own super short versions of links, it checks to see if the link owner has published a shortened version of the given page using HTML link element. If not, we just return the original URL. And you should bug the link owner about providing a better alternative.
]]></description>
<dc:subject>web architecture webservices linking hypertext html standards</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:006478b9f7b6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:webservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:linking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:hypertext"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:html"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.w3.org/TR/2008/NOTE-cooluris-20081203/#r303gendocument">
    <title>303 URIs forwarding to One Generic Document</title>
    <dc:date>2009-03-25T17:34:15+00:00</dc:date>
    <link>http://www.w3.org/TR/2008/NOTE-cooluris-20081203/#r303gendocument</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The server forwards from the identification URI to the generic document URI. This has the advantage that clients can bookmark and further work with the generic document. This setup should be used when the RDF and HTML (and possibly more alternative representations) convey the same information in different forms.
]]></description>
<dc:subject>semweb architecture web design identity linkeddata naming</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:0a4fefa3facf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:semweb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:linkeddata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:naming"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Dec/0416.html">
    <title>[whatwg] Trying to work out the problems solved by RDFa</title>
    <dc:date>2009-01-13T20:45:52+00:00</dc:date>
    <link>https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Dec/0416.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[It would seem important that the Web easily enable small-time users of data to efficiently communicate with one another, without the need to have one of the giants as an intermediary.
]]></description>
<dc:subject>opinion semweb rdfa metadata architecture search web inls620</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:d7c668469b42/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:opinion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:semweb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rdfa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:metadata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:inls620"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://slurl.com/about.php">
    <title>SLurl: Location-Based Linking in Second Life</title>
    <dc:date>2008-12-10T19:43:26+00:00</dc:date>
    <link>http://slurl.com/about.php</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[SLurl provides direct teleport links to locations in Second Life. If you have Second Life installed, clicking on the map link will automatically teleport you to that location in-world.
]]></description>
<dc:subject>reference 3d metadata architecture web place secondlife virtualworlds identification</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:90e3e93f206e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:3d"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:metadata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:place"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:secondlife"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:virtualworlds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identification"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">
    <title>REST APIs must be hypertext-driven » Untangled</title>
    <dc:date>2008-10-20T17:27:09+00:00</dc:date>
    <link>http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types).
]]></description>
<dc:subject>rest architecture api design</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:9f81fd11287c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://web.fumsi.com/go/article/manage/3126">
    <title>FUMSI -- Helping you Find, Use, Manage and Share Information</title>
    <dc:date>2008-10-15T16:00:05+00:00</dc:date>
    <link>http://web.fumsi.com/go/article/manage/3126</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[This two-part article is a step-by-step guide for those wishing to create new taxonomies for their business unit, or client. It will outline the many different elements that make up a quality taxonomy and the pitfalls you should be aware of when starting a new project.
]]></description>
<dc:subject>classification taxonomy information architecture methods design analysis howto</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:bb6df58af131/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:classification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:taxonomy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:information"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:methods"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:howto"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.jstor.org/stable/2629118">
    <title>Decentralization by Function and Location</title>
    <dc:date>2008-08-14T17:13:37+00:00</dc:date>
    <link>http://www.jstor.org/stable/2629118</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Under what conditions is decentralization of facilities rational for a client-centered system of service or administration, and when is great centralization more cost-effective?
]]></description>
<dc:subject>decentralization systems analysis design networking economics architecture planning</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:8f8c923de79c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:decentralization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:economics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:planning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2">
    <title>Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)</title>
    <dc:date>2008-03-23T00:29:51+00:00</dc:date>
    <link>http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
]]></description>
<dc:subject>rest architecture web</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:f80ea85ef3aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://roy.gbiv.com/untangled/2008/on-software-architecture">
    <title>On software architecture » Untangled</title>
    <dc:date>2008-03-23T00:26:44+00:00</dc:date>
    <link>http://roy.gbiv.com/untangled/2008/on-software-architecture</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[REST maximizes the growth of identified information within a multi-organizational, network-based information system, which increases the utility of the system as a whole.
]]></description>
<dc:subject>rest architecture style web identity information</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:c624233f5abf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:style"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:information"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rubyforge.org/projects/conveyor/">
    <title>RubyForge: Conveyor: Project Info</title>
    <dc:date>2008-02-27T06:48:20+00:00</dc:date>
    <link>http://rubyforge.org/projects/conveyor/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Conveyor can be used like an application-agnostic version of MySQL binlogs, which can be replayed to write data into multiple, diverse data stores.
]]></description>
<dc:subject>web data architecture code ruby database search</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:c33b2ce74546/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:code"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:search"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://incubator.apache.org/uima/">
    <title>Apache UIMA - Apache UIMA</title>
    <dc:date>2008-02-20T05:49:00+00:00</dc:date>
    <link>http://incubator.apache.org/uima/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The Unstructured Information Management Architecture (UIMA) is an architecture and software framework for creating, discovering, composing and deploying a broad range of multi-modal analysis capabilities and integrating them with search technologies.
]]></description>
<dc:subject>extraction recognition architecture tools java datamining search</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:b4897f743e8a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:extraction"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:recognition"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:datamining"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:search"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://developers.facebook.com/thrift/">
    <title>Facebook Developers | Thrift</title>
    <dc:date>2008-02-04T21:13:37+00:00</dc:date>
    <link>http://developers.facebook.com/thrift/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[A software framework for scalable cross-language services development. It combines a powerful software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, and Ruby.
]]></description>
<dc:subject>code opensource c++ java python php ruby communication architecture interface</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:12979a0da868/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:code"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:opensource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:php"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:interface"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cmlenz.net/archives/2007/10/couchdb-joins">
    <title>CouchDB &quot;Joins&quot;</title>
    <dc:date>2007-12-23T01:25:07+00:00</dc:date>
    <link>http://www.cmlenz.net/archives/2007/10/couchdb-joins</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Views map keys to values, where the key is automatically indexed and can be used to filter and/or sort results. Keys can be any JSON object, which enables a whole class of tricks that are rather non-obvious…
]]></description>
<dc:subject>distributed database architecture howto javascript</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:b48551a2e453/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:howto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.freebase.com/view/guid/9202a8c04000641f8000000003e0318a">
    <title>Architecture GIS App : Freebase</title>
    <dc:date>2007-11-28T01:04:09+00:00</dc:date>
    <link>http://www.freebase.com/view/guid/9202a8c04000641f8000000003e0318a</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Note: trying to filter by state, or country is very difficult with our current data.  The U.S. cities are pretty good but international location data is very spotty.
]]></description>
<dc:subject>freebase architecture GIS locative</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:028981a4e403/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:freebase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:GIS"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:locative"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dannyayers.com/2007/11/14/hash-soup">
    <title>Hash soup</title>
    <dc:date>2007-11-22T01:35:45+00:00</dc:date>
    <link>http://dannyayers.com/2007/11/14/hash-soup</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[The significance of the whole URI in a representation language designed for human consumption is likely to be different than its significance in a language designed for machine consumption. What matters is consistency in the protocol.
]]></description>
<dc:subject>web architecture uri design</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:c04efd250a39/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:uri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://purl.org/">
    <title>Persistent URL Home Page</title>
    <dc:date>2007-11-15T18:05:36+00:00</dc:date>
    <link>http://purl.org/</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Instead of pointing directly to the location of an Internet resource, a PURL points to an intermediate resolution service.
]]></description>
<dc:subject>web architecture persistent archives identity</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:e0e73729836e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:persistent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:archives"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mjtemplate.org/examples/rison.html">
    <title>rison - json for uris</title>
    <dc:date>2007-11-13T17:53:12+00:00</dc:date>
    <link>http://mjtemplate.org/examples/rison.html</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[Rison is a slight variation of JSON that looks vastly superior after URI encoding.
]]></description>
<dc:subject>data javascript web architecture design</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:c7d32155a3fc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://danbri.org/words/2007/09/13/194">
    <title>danbri’s foaf stories » “The World is now closed”</title>
    <dc:date>2007-09-17T18:48:30+00:00</dc:date>
    <link>http://danbri.org/words/2007/09/13/194</link>
    <dc:creator>rybesh</dc:creator><description><![CDATA[If we’re aggregating (and building UI for) ’social web’ claims about the world rather than simple buddylists, I suspect aggregators will get burned unless they take care to keep careful track of who said what.
]]></description>
<dc:subject>social web identity opendata provenance semweb metadata architecture design</dc:subject>
<dc:identifier>https://pinboard.in/u:rybesh/b:b9dbf01bfb33/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:social"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:identity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:opendata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:provenance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:semweb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:metadata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:rybesh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>