Re: Loyalty / Privacy RDF (Like Creative Commons, for loyalty permissions).

Interesting article surrounding the subject; http://www.onlineopinion.com.au/view.asp?article=16462&page=0


Sent from my iPad

> On 1 Jul 2014, at 6:13 pm, Timothy Holborn <timothy.holborn@gmail.com> wrote:
> 
> HI All,
> 
> In the last web-payments teleconf. An idea came to light around defining loyalty permissions in a manner similar to creative-commons.  
> 
> For the uninitiated;’ creative commons serves RDF, which means the license data is available in machine readable format.  An example of the use of this function includes the creative clipboard [1] and of course the creative commons search [2].  
> 
> In other formats of identity disclosure, such as FOAF [3] - FOAF files can have access control amended to the files, which via a URI simply provide permissions.  Open-cards might be used to create address books [4], which i believe is still being generated by bbl fish [5], and in future iterations of platforms like ODS [6] (assuming the platform can manage domain services, like email) unique information could be generated for the purpose of supporting single loyalty relationships, as to abstract the information in a manner that would diminish the usability of addresses for nefarious purposes.  Example could be facebooknotifications+myaddress@myemail.tld - which, i note, is already used by gmail [7], understanding the concept, should a user personally control a domain, be something that could be used in a far more sophisticated manner (ie: only accept email from xx@ domain to xx@ address, etc.).
> 
> So, whilst their are ways to hamper access - It seems reasonable that people should seek to separate the identity needs of carrying out a transactions (needs defined as practically required needs, not ‘wish list’ made requirement by merchant) and similarly; the ability to create permissions of some-sort on loyalty relationships; and, perhaps this could be described in a manner similar to Creative Commons.
> 
> The second aspect; is whether or not it’s plausible to store and ‘track’ (or audit) the amount of times a persons details are used by a 3rd party.
> 
> Given systems such as FOAF simply using a URI [5] - in theory a permission could be created that says ‘do not store’, which means every time the data is used for some-reason - it needs to be acquired again from the originating source.  One might consider that this would be done from time-to-time in any case, as the FOAF URI is maintained in a manner more reliable than traditional SQL storage after acquisition (for some transaction related reason, for example).  Other consideration is that the quality of information would improve due to the same reasoning.   In a way, this may be considered to be similar to the process of tracking direct mail deliveries.  I know, from the days of running a pizza store, it’s difficult to know whether the flyers were being delivered, or just dumped into a bin somewhere.  Equally, it would have been good to target - yet somewhat impossible to do so, given the technology of the mode of advertising delivery.  
> 
> So, in a roundabout way - i wanted to ‘pitch’ a broad brushed concept of how privacy/loyalty data permissions might be described using both a creative commons like format; and, FOAF. 
> 
> The information relating to loyalty has no fiduciary responsibility attached to its accuracy.  It is obviously a format of data-use which is opt-in, and therefore sought to be mutually beneficial - like being good ‘mates’ with the greengrocer as a benefit to the relationship; rather than, having an expectation that the transaction occurred specifically as expected for legal purpose.
> 
> These two fields are mutually independent, and given the platform (WWW) - if we are to enable small retailers to implement POS systems that have WWW interfaces, considering the elements of ‘trust’ is important, and as such the accountability measures (whilst not necessarily enforceable) could at least be stated; which in-turn provides the market an array of means to engineer enforceability measures, such as reputational stakes (akin to your web-browser or seach-engine saying ‘this website is malicious’) and other factors.
> 
> Herein; i think it’s important to consider that psychologically, people ‘trust’ larger portals with transactions whether or not it’s actually safer to use them.  For an unknown website, build using basic software (say, wordpress, or simply HTML, but not like shopify, ebay, amazon, etc.) the ability for a person to trust that both the carriage of the transaction is fulfilled AND they’ve at least been able to define upon what terms their information can be used in future by that site (implicitly perhaps also, not sold to some mailing list company or similar) I think is a reasonable function to consider.  Perhaps the most compelling reason - it would significant enhance the support capability for SME’s to goto market with WWW interfaces to their small business activities and in-turn, act as another tool for loyalty relationships broadly.
> 
> CONSIDERATIONS ALSO
> 
> 1. Turtle = serialisation for FOAF (and other RWW stuff) is in turtle.  support for turtle is perhaps needed more broadly, but is certainly debatable.
> 2. Identity vs. Persona = identity is needed for legal purposes, persona is a form of personalisation or business card.  i.e.: i purchased this item (identity) on behalf of my company (persona / agent).
> 3. distributed storage of user-data (see cloud storage [8]) 
> 4. IMHO - Accountability is a predicate to Trust. accountability is more difficult to ‘Hack’ than ‘Trust’, and if trust is ‘hacked’ then the systems accountability measures have failed.. 
> 
> COMMENTS = PLEASE>>>>  
> 
> Cheers,
> 
> TimH.
> 
> 
> [1] http://dig.csail.mit.edu/2009/Clipboard/
> [2] http://search.creativecommons.org/
> [3] http://xmlns.com/foaf/spec/#term_Agent
> [4] http://linkeddata.github.io/rdflib.js/example/people/social_book.html
> [5] http://bblfish.net/people/henry/card#me
> [6] http://demo.openlinksw.com/ods/
> [7] https://support.google.com/mail/answer/12096?hl=en
> [8] http://www.w3.org/DesignIssues/CloudStorage.html