Abstract

Projects are being assigned this week. The three project areas are Location, Linked Data, and Feed Technology. Each of these areas has data model and service components. In all project areas this week is dedicated to learning more about the project environment, and existing technologies and approaches. This week's work will allow students to give initial presentations about their project next week, serving as a starting point for further work and possible collaborations among projects.

Individual Locations

Social Places

• Locations and location-based services are popular themes
• Most applications are based on closed scenarios
  • location information is made available only to special providers (mobile scenario)
  • location information is only usable within one silo
• Tasks for first week:
  • develop scenarios for sharing location information across services
  • how good is Fire Eagle for this? (centralized)
  • start collecting map URIs as a test dataset for mapping map URIs
• Next tuesday:
  • present the PlaceML data model and possible services around it
  • present some first ideas about location services and social networking
• Next goals:
  • Services for locations and places without being restricted to geolocation

Map Mapper Map (Read)

<mapmap version="1" revision="$Rev: 155 $">
 <service id="google" separator="&amp;" match="^http://maps\.google\.com/maps" non-match="msid=\d+" name="Google Maps">
  <info href="http://mapki.com/wiki/Google_Map_Parameters" title="Google Map Parameters - Google Mapki"/>
  <read>
   <part id="address" pattern="q=(.*?)&amp;"/>
   <part id="lat" pattern="ll=(.*?),.*?&amp;"/>
   <part id="long" pattern="ll=.*?,(.*?)&amp;"/>
   <part id="view" pattern="t=(.*?)&amp;">
    <token pattern="m" value="map" default="yes"/>
    <token pattern="h" value="hybrid"/>
    <token pattern="k" value="satellite"/>
    <token pattern="p" value="physical"/>
   </part>

Map Mapper Map (Write)

  <write prefix="http://maps.google.com/maps?">
   <part base="address" pattern="q=$1"/>
   <part base="lat long" pattern="ll=$1,$2"/>
   <part base="view" pattern="t=$1">
    <token pattern="map" value="m" default="yes"/>
    <token pattern="hybrid" value="h"/>
    <token pattern="satellite" value="k"/>
    <token pattern="physical" value="p"/>
   </part>
   <part base="zoom" pattern="z=$1">
    <token pattern="19" value="19"/>
    <token pattern="18" value="18"/>
    <token pattern="17" value="17"/>
    <token pattern="16" value="16"/>
    <token pattern="15" value="15"/>
    <token pattern="14" value="14"/>

Map Services

• Map services support map bookmarks by using URI UIs
• What about using these as URI APIs?
• There is no standard for map URIs
  • there is a pretty small common set of parameters for controlling a map
  • creating a data model for these parameters formalizes the API
• Tasks for first week:
  • take the existing Map Mapper Map and add new map services
  • maybe add new parameters to the data model (if required)
  • maybe improve the mapping process to be more flexible and powerful
• Next tuesday:
  • present the updated map and its model
  • point to challenges and problems which need to be solved
• Next goals:
  • collecting enough URIs and services to define a robust mapping scheme

Compound Documents

• Many resources on the Web are actually compound resources
• HTML has rudimentary support for expressing resource relationships
  • some connections are explicit (img, object, CSS URIs …)
  • others are implicit and require understanding (a)
  • many are hidden deep in scripting code and maybe even dynamically loaded data (Ajax)
  • link sometimes helps but is not very popular
• Various vocabularies have been developed to represent links
  • XLink, METS, DIDL, OAI-ORE, …
  • so far, none of these has been successful on the Web
• Tasks for this week:
  • compile a complete dictionary of all HTML linking constructs
  • work on a list of issues which are hard or impossible to solve
• Next tuesday:
  • present all ways in which HTML & CSS connect resources
  • present a first rough outline of an algorithm for identifying compound resources
• Next goals:
  • tweak the algorithm to be configurable so that it can be customized as a harvester

Accessing Link Data

• Links (such as information about Compound Documents) are discrete resources
• Atom and AtomPub have been designed to manage collections
• Instead of just serving content, a link feed could serve context
• Tasks for this week:
  • read AtomPub and look at the Atom landscape
  • think about how AtomPub could be extended to be timeless
• Next tuesday:
  • brief presentation of the issues with AtomPub in this scenarios
  • making the connection between Compound Documents and link feeds
• Next goals:
  • more research in AtomPub extensibility

Internet Archive

• Archiving of (more or less) any kind of data
  • rsync for syncing complete file systems
  • FTP for uploading items in a one-by-one process
  • HTML form for upload which also only allows one-by-one upload
• Tasks for the first week:
  • inventory of currently supported interactions for content providers
  • inventory of currently supported interactions for content consumers
  • start work on lists of possible improvements (focusing on content, not UI)
  • read AtomPub and look at the Atom landscape
• Next tuesday:
  • presentation of data flows in and out of the Internet Archive
  • brief overlook of how Atom and AtomPub fit into that picture
• Next goals:
  • would it be possible to build a mod_atom interface for the archive?

Exploration

• Introductory reading and some first experiments
• Your (last) chance to choose the direction in which you are going
• My goals and interests are not necessarily yours …