Note: This only works in FF right now, I'm too lazy to fix the XSL stuff for IE until I get some other mechanics right
This is in no way set in stone. All steps and techniques container this document are conceptual in nature and have been
setup to show a function, and that function only --- runtime data discovery and aggregation.
So my pal Paul Jones wants to pull all of his images into floe.tv's editor to mix them into a slideshow, and he
really doesnt feel like manually adding each api or remembering where he last uploaded a photo (myspace? flickr? facebook?)
He just wants to make a slideshow and share it --- because thats the core of the user experience
In this demo we'll see
A conceptual Data Portability Services Catalog (wNode) being queried for a type of Data Container (images)
Then we take those image data container uris, and query each one for their WADL - this gives us the 'vocabulary' on how to talk to that unique api
The next stage has us pulling the xsl transformation file from the server so that we know how to translate the data into a common ontology format
Then we actually pull the required data, and run the xsl transform into (for the sake of this example, a non-lossy rdf dialect).
Site A and B now have their data in our local cache as site neutral RDF data. We merge these recordsets into a single recordset for delivery.
Now we take into consideration that to be a turn key based system, we'd like to give the user the option to choose a desitnation render ontology or microformat, or provide
their own xsl url so that we can render it for them (note: obviously allowing them to get at the intermediary RDF/xml is an option as well, but we're just trying to design for
a simple solution that gives a very strong default end to end solution
Stage 1: Identity Discovery
Step 1. Query the Services Catalog Index (wNode)
Stage 2: Data Container Negotiation
Image Site A - Legacy System, Minimal Codebase Impact
Notice that image site A is taking default locations for both the WADL and the XSL files. This means
that the system will look in a specific location relative to the root directory for both the wrfs_wadl.xml file and the
wrfs_transform.xsl file.
This type of site would be an example of a site that has a legacy api, but active supports data portability initiatives;
It is actively updating the user's Services Catalog on the user's behalf, and it also exposes a WADL file to describe to third parties
how to talk to its legacy api. This site is continuing to do business as it always has, and supporting data portability and wrfs has minimally impacted
their codebase. All they had to add was the Service Catalog update method, and 2 files in their root directory: the wadl file (wrfs_wadl.xml) and the xsl file (wrfs_transform.xsl)
so that their data format did NOT have to be changed (nor their legacy api), and all they had to provide was a xsl document to translate their xml dialect to the common ontology for
data portability.
Render the raw data into a neutral format for merge/aggregation
Now Lets do the other Image Site
WADL
XSL Transform
Data Returned
Now Render the raw data (from site B) into a neutral format for merge/aggregation
Stage 3: Data Merge
Two Sets of Data Enter; One Set of Data Leaves!
Ok, now that we've used the site supplied translation XSL document that tells how to render their unique
xml format into a application neutral common intermediate ontology, we can merge the data into a single
store.
Stage 4: Data Render
Paul's Unified Image Stream
At this point we have our desired data in a single format non-lossy neutral data ontology for images. What
we want to do now is simply show some render options for a final application-layer deliverable to
demonstrate just how easy it would be to use a system like this, end to end.
Redux: Comments and thoughts
What did we do here?
Discovered where a user kept their images online
Talked to each data store to find out how to communicate with their custom api
Talked to each data store to find out how to translate its data into a common data type
Gathered the data from each store and merged it into a single recordset in a non-lossy fashion
Rendered the data payload into a desired format to show how turnkey using the framework could be - it could drop right in any application
What did we NOT do here? (but would normally)
Authenticate with openID and discovered the location of the service catalog
Used OAuth + Discovery to get permissions to read data
How do we get better?
Show openID authentication with discovery of Service Catalog
Show working Service Catalog
Show OAuth protecting resources
Create lib_WRFS { js, php, C#, py } for end users to achieve a truly turnkey experience
Show more WRFS api type capabilities { querying via SPARQL, api call params and filters }
Show how quickly a legacy api site could get linked in
Show how quickly a new site could get a shiny whitebox api and have data access out of the gate
Discuss how content-types map to translations, and what would common ontologies look like for the intermediate data
Show working with caja for js-cross domain data access