Re: Use Case Refactoring v1.0

USE-CASE REVIEW

NOTE:  Read-write-web[1] is under active development through a W3 Community Group [2] and it is my belief, that the products / product concepts, being developed in concert with this initiative will offer a long-term solution to the ‘wallet’ issue.

Examples include data.fm, rww.io, stample.co, OpenlinkSW ODS [3].  Issues pertaining particularly to ‘web-credits’ IMHO, include issues about how keys may be managed within an environment that has institutional expectations, and an array of different use-cases for which we simply need to support functionality, rather than defining capabilities, iteratively.  I also believe that the concept of a ‘wallet’ is not simply about legal tender.  Whether it be a contract, a license attached to some code or data-object, the wallet facet of functionality should in theory provide accountability at a minimum.  

IMHO - building POC work with data.fm seems like a viable approach, understanding the politics around whether we’re building standards or software; i’m not sure. Perhaps that question is best answered with a license type.   in any case;

http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf I found useful when considering the functional objectives of a baseline around ‘values’ required by a receipt system. 

I see in the existing spec; https://web-payments.org/specs/source/web-commerce/ - there is an asset hash, and the concept of a license.  I pose a question (subject to the analyse below) that perhaps the ability to trade identities also becomes important, therein; separating the concepts of a basic asset (that can be referenced as a unique thing / batch / etc.) and a sophisticated asset (that interacts on a continued basis with supply / distribution chains). 

asset = something that can be traded.

CONCEPT SUMMARY

RULES vs. Commerce Data vs. Community Data 

There seems to be a few different areas of data; depending on the type of data, benefits of accountability for that data changes from data required for commercial / legal purpose; through to tangential or community data.   I’ve attempted to outline some ‘fields’ of data pools to aid discussion about ACL’s and resilience of data-accessibility & Accountability with relation to receipt information…


RULES DATA = which are RULES that can be predefined or varied subject to RULES.   In theory these types of data-objects (linked data objects?) need to be referenced in a manner that is fixed or controlled by authorised entity.  these forms of data may include warranty or governance related information, etc.

COMMERCIAL DATA = linked-data that is applied to transactional information in a manner that is important for the continued fulfilment of commerce throughout the lifecycle of something that related to a transaction.   This information appears to also require governance constituents, which support the legally binding nature of commercial agreements / commerce, such as the requirements put upon a receipt for taxation purposes. 

COMMUNITY DATA = commons data, that may have incremental support for commerce but is not required as a constituent of a legally binding agreement.

I consider this type of data to be similar to wikipedia in nature, where it can be community governed without infringing upon the rights of individuals, and may be considered ‘free speech’ otherwise, as governed by the content providers directives (i.e. wikipedia / Facebook, etc.).
 
ENTITIES & TRANSACTIONS  (simple / sophisticated - asset analysis)
It appears that complex products and trading entities are ‘entities’ for the purpose of managing receipt data throughout an array of potential web-payments use-cases.  Whether it be a cow, a vehicle, a government entity providing authority upon a shipment of a product which is destined to be subsidised, collaborative community development of a project or a document that incorporates an array of 3rd party content; each of these ‘entities’ are then related to an array of ‘creator’ and distribution chain entities, where relationships and qualities are developed overtime attributed to all involved entities for an array of different purposes.

It is not the purpose of the group to define all the variables or content pools; but rather perhaps, provide the scope of opportunity for others to do so, in a standards compliant manner…  

BLOCK-CHAIN AND RELATED TECHNOLOGIES (DISTRIBUTED HASH TABLES, ETC.) 

As illustrated by HTTPA, and some of the implementation of BlockChain Technologies; an array of methods are becoming available to secure accountability (including privacy provisions) around transactional data.  Does the web-payment business case require the establishment of some sort of root-node for unique asset-id’s? 


LINKED DATA AS A CRITICAL INGREDIENT TO OPTIMAL DIGITAL RECEIPT SYSTEMS. 
It is likely that industry verticals will require registry systems, that provide some metadata-registry type services (i.e.: schema.org, freebase.com ) whilst also supporting an open-source implementation methodology that is made accessible, as a constituent to supporting ‘on-boarding’, and take-up, of the web-payments spec; whilst establishing supportive systems that may be specific to industry vertical or horizontal demarkation points. 

—> Linked Data Platform and Read-Write Web seem to be solutions that collaboratively support the requirements, whilst also attending to a need of seeking further community enhancement in developing cross-segmentational approaches, to solving these web-scale problems / opportunities.  

—> perhaps it is not about the service, but rather applying a standard to existing services, such as those that are similar in nature, and being delivered by the likes of google for search purposes currently.

Digital Receipt systems also offer information that is required for promoting a product, as much of the information provided, should be the same as the promotional info.  

— > Ownership, business systems and data-points for ACL’s (i.e.: WAC) around linked-data throughout the supply chain, from a visibility point of view is an unanswered consideration.  Meaning, perhaps the standard should support specified options, rather than being iterative about deployment methodologies…? 


USE-CASES - SupplyChain analysis / concepts

To explore the concepts, i’ve outlined some business cases / use-cases, that have sophisticated opportunities for the use of linked-data.  

Per Below:


Perishable Goods
A cow is produced by some form of fertilisation.  they’ve got history graphs, genetics, around cows for sale.  There is then an array of classification markers and a farmer gets a cow, breeds that cow in a certain area, until the farmer chooses to sell that cow to another entity.  

- COW Has UNIQUE ID (perhaps linked to RFID or tag) 
- Farm has GIS co-ordinates
- Farm has economic ID (legal entity = farm, operated by, managed by, etc.) 
- Farm GIS / Economic ID has track-history - could include, rainfall, farm fertilisation history, vet history, company history and social ratings / rankings from former suppliers, etc.

From this point, the digital receipt only really needs to identify the cow, and give it a unique ID.  All the tangential stuff relating to farming could be produced by some industry vendor creating RDF Resources (ontology, registry, etc.) that could be used by that specific industry, in the country of origin.  practices, language and requirements change from country to country and they’d need a way to link records across markets.

Cow gets butchered; parts are sold for different food products, to different locations.   

Supermarket might present a 2D barcode (QR Code) for a retail shopper to ‘capture’ if they’re really interested in the provenance of that food.  

Information might include data that’s supplied to support medical requirements (allergies an end-user has; privately linking data between medical record systems and food-supply information systems).  Ideological information (we don’t by caged pigs), religious information (it’s halal, or kosher produce) and accountability metrics support reverse engineering should something go wrong (cow gone mad) or there was a problem with the supply-chain (we’re worried it was a horse, not a cow and when we buy cow, we want cow, not horse <-> medical RDF?).

GOING GREEN
Government likes the idea of supporting the introduction of solar panels, long-term charging point / day-time parking spaces as a council revenue model; with plug-in, electric vehicles that can be used as grid-utilities at night to stabilise the grid, understanding more electricity is used at night, when the solar panels aren’t working.

Factory in a very poor region of the world says they’re able to produce cheap solar panels.  Government employee in foreign land (delivery territory) is chartered with a responsibility to come-up with a tax-payer funded number that supports the lowest-cost (with an acceptability matrix) introduction of solar panels, and policy makers need to know what that price is.

Customs tags products with ‘approvals’ via some legislative means that maintains ‘territory standards’ for sale or participation in the program; these ‘certificates’ are then associated to the product throughout retail territory distribution systems; and can be required as part of the economic process of an end-customer receiving a subsidy for their purchase. 

As part of the analyse, an environmental engineer and accountant is sent-out to the factory to obtain a global environmental certification for the factory.  Their recycling and waste-management (amongst other things) are taken into account, which in-turn provides a linked-data rating system that can be factored into the calculations required by the gov. employee within the distribution region, who needs to deliver a number of ‘least expense’ for the purpose of tax-payer subsidies for the encouragement of supply for ‘green technologies’ and energy management systems.

— the same type of methodology can also apply to the vehicle.  the vehicle may generate funds when being used as a grid-service, whilst expending funds whilst being driven.  whether these funds are energy units, or dollars converted to energy units - outside of scope, but perhaps different units may exist that allow a consumer to select how they get their power.

COMMUNITY INVESTMENTS:  Perhaps, the vehicles have a preference stored in them, that creates a demand register for the implementation of renewable energy.  Perhaps, rather than the vehicle owner owning the battery - its part of an energy service, that allows the vehicle owner - on long journey’s - swap the battery out, to continue that long-journey, being charged for energy units (of some form) rather than for the cost of a replacement battery (perhaps other than service-station fees). 

COLLABORATIVE DEVELOPMENT
Bunch of people blog away on a list somewhere, towards a common-goal.  the common-goal has a unit cost, that scales overtime.  contributors are awarded by some sort of approved ‘ping back’ service, for meaningful contributions that in-turn provide a participation in a value relating to the overall contributions (in all languages / medium) towards the achievement of that end-goal.  The End-Goal is tracked by use. If it becomes ‘ubiquitous’, then good work everyone.  If no-one uses it, then hopefully the group had a bit of fun in their journey of discovery. 

Equally; as the Semantic Clipboard considers [4] the ability to copy an image, in-turn brings about the ability to license an image.  This concept of acquiring data-assets easily with an attributed value, could provide enormous economic opportunities for many working on computers as a means for economic purpose broadly.  Regardless of the frontier of the digital object, those publishing works often seek to use a network of different assets resourced from across the web which contribute towards a new innovative product, that in its own right has merit, and depending on the use-case, different licenses may apply.

If a product is to be given freely (/attribution only) for specified purpose (i.e. education, non-profit) this should not disallow separate licenses for commercial purpose (i.e. commercial use, commercial use by organisation that is not a start-up (or subject to a set or rules), etc. ) 

SUMMARY
No-Matter how user-data is stored, the capacity and purpose of considering ‘linked data’[5] and the business case of existing applications becoming Webized [6] brings into consideration an array of new concepts that have merit, in an array of new ways.  In considering the spec; i’ve attempted to parse a lens over the specification, with Web 3 - Linked Data  - Semantic Web, in mind.  

In considering the outcomes surrounding this viewport; perhaps an array of ‘assets’  should have a unique ID, that can merge with other ID’s throughout a supplychain, for specified purpose.  When considering this in relation to how it could be done, the concept of WebID Comes up, yet the view was via FOAF to call a person an AGENT who “should be able to control their identity”, yet obviously there is a difference in the definition of ‘asset’ vs. ‘agent’ and of course, for the purposes of FOAF and other means, ‘PERSON’ or ‘Legal Entity’ (whether incorporated or natural).  

pre-web (perhaps pre RDF web) technologies could not track easily, so much of the knowledge as is intrinsically linked to the production, distribution, use and destruction of a ‘thing’.  The potential benefits for considering how these types of data-points might be used by society at large; i believe justify considering how to support it in this spec.  

Perhaps it is already; and i’ve not figure out how it applies…  Please feel welcome to tear these concepts to pieces, and identify how to improve the concepts as they should apply to the standard. 

Cheers.

TimH. 



[1] http://www.w3.org/DesignIssues/ReadWriteLinkedData.html  
[2] http://www.w3.org/community/rww/ 
[3] http://ods.openlinksw.com/wiki/ODS/
[4] http://dig.csail.mit.edu/2009/Clipboard/ 
[5] http://www.w3.org/DesignIssues/LinkedData.html 
[6] http://www.w3.org/DesignIssues/Webize.html
[7] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

On 25 Apr 2014, at 12:51 am, Andrew Mackie <andrew@supplydemand.info> wrote:

> Following a conversation with Manu and Brent last week, I've started the task of categorizing the use cases from a conceptual standpoint in order to ensure that a) we include every use case that we need and b) the final set of use cases is well structured to aid understanding. 
> 
> To do that, I have taken all of the current use cases (from https://www.w3.org/community/webpayments/wiki/ClassifiedWebPaymentsUseCases_r1) and put them into a mind map to determine and map out their structure. 
> 
> The first version of this mind map file (.mm) and an XHTML export of that file can now be found here - http://www.supplydemand.info/blog/web-payments/
> 
> As you can see, I've added a number of comments and questions and I've identified a number of gaps that we need to fill in. I will continue to play with the structure - in the meantime I appreciate your comments, answers, identification of gaps and so on. Once I've     cleaned it up some more and incorporated this initial feedback I'll find a way to open it up for a more immediate / open form of collaboration (and any suggestions on the best format are welcome!).
> 
> Cheers,
> Andrew 
> 
> -- 
> Andrew Mackie
> website: www.supplydemand.info
> twitter: @SupDemand