extended readme, added alternative ids

README.md

@@ -1,4 +1,3 @@
-
 # Stations
 
 ## Why this project?
@@ -11,15 +10,32 @@ For example, when one dataset from a bus company is opened, it takes a lot of fi
 
 ### Proposed solution
 
-Using the vocabulary we have discussed at [opentransport/transit-vocab](http://github.com/opentransport/transit-vocab) we will set up a site which can reuse data from various sources and link them all together.
+Using the vocabulary we have discussed at [opentransport/vocabulary](http://github.com/opentransport/vocabulary) we will set up a site which can reuse data from various sources and link them all together.
 
 ## What should it look like?
 
-... work in progress
+It should have functions for three different end-users:
+* Data owners: add a link for datadump of stops which can be automatically fetched. Provide mappings to the stations.io scheme.
+* Data consumers: get the right datadump for your application with the right IDs from different systems
+* Data enrichers: add data for one specific stop
+
+### Extra data owner use cases
+(e.g. an open street map contributor or a transport agency employee)
+
+* Clean datasets and do named entity recognition
+* Link to global `stop_area` and `stop_point` IDs
+* -add yours-
+
+### Extra data consumer use cases
+(e.g. an app creator, a map designer or an accessibility researcher)
 
+* An autocomplete list generator
+* Get the right `connection_link` times to create links between modes
+* -add yours-
 
-## Use cases to keep in minds (add yours)
+### Extra data enricher use cases
+(e.g. an app creator who wants to provide a feedback button in his app, an integrator who finds mistakes in the dataset, a transport company that is moderating the data, and so on)
 
-* An autocomplete list generator for end-user applications
-* Intermodal route planning software can use this website to know which stops can be used as transfers to other systems
-* ...
+* Being able to do PUT and POST requests on a URI
+* A simple interface to view, edit and add feedback to a representation
+* -add yours-

uristrategy.md

@@ -6,9 +6,16 @@ We need to agree on a URI strategy before giving ids to everything in the world.
 
 ## Strategy
 
-The root: http://stations.io/
+All URIs will return a HTTP 303 towards this URL: {URI}.about.
+This .about will check what format the client wants using content negotiation (or can be overwritten with ?format=...)
 
-Further paths' semantics follow the opentransport vocabulary:
+Formats to be supported: CSV, XML, JSON, RDF, TTL, N3
+
+### The root: http://stations.io/
+
+On this site the 
+
+Further paths' semantics follow the OpenTransport vocabulary:
 
 ### /{object}/
 
@@ -22,12 +29,15 @@ Gives a list of all stop_areas if no id is given. If an id is given, it will ret
  * links to connections
  * ...
 
+For each different id system, a new alias system will also be put in place which the URLs will redirect to the general URI of stations.io. Thus `stop_areas/{alternative_system_name}/{alternative_id}` will redirect to `stop_areas/{id}`
+
 #### stop_points/{id}
 
 Gives a list of all stop_points if no id is given. If an id is given, it will return the information we have about this stop_point and the relation to the other things in our system.
 
+For each different id system, a new alias system will also be put in place which the URLs will redirect to the general URI of stations.io. Thus `stop_points/{alternative_system_name}/{alternative_id}` will redirect to `stop_points/{id}`.
+
 #### connections/{id}
 
 Gives a list of all connections if no id is given. If an id is given, it will return the information about connection and the relation to the other things in our system.
 
-