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

https://www.abine.com/index.html is an example of an alternative format for privacy management…


On 3 Jul 2014, at 3:33 pm, Tim Holborn <timothy.holborn@gmail.com> wrote:

> Heya,
> 
> I’m not sure the lens used in your reply; so, i’ll try to describe where i was heading with the concept in more detail...
> 
> Where i saw ‘gaps’ were that i couldn’t find a ‘creative commons like’ mechanism to - in a legally relevant context - describe permissions relating to furnishing personal privacy principles - related information; nor could I identify a suitably developed marketing scheme, similar to the Creative Commons iconology and related manifest functional properties; or indeed the ontological mechanism and stakeholder-group where this group of functional properties might both be in-existance (used already), adaptable, supported, etc.
> 
> https://creativecommons.org/choose/ is kinda simple.  It has iconology, easy to intepret definitions and more complex license related documents which relate these simple user-interfaces to legal principles, in an array of countries more specifically orientated to support their rules of law; etc.
> 
> So whilst i’ve got not fixed view about the method (being which ontology specifically); i think the capability is worth considering and therein, researching formats in how such a functional property might be included in the spec.  
> 
> As noted below (my inline response) - it is not my suggestion that we are able to prevent access to data already furnished to a 3rd party (and their relational DB) for the purpose of fulfilling a transaction; but rather, supporting the capacity to define expectations relating to how that information may be used, who by, etc.   I note however, that should a log be provided (digital receipts) to the identity provider in relation to commercial interactions with a merchant - these terms may be stored mutually, rather than only retaining the declaration within a merchants system. 
> 
> regardless; It is plausible that the answer may be ‘we are not willing to include this’, which would be different to ‘it is impossible to include this type of function’; and broadly, i consider that it may be a request that includes an array of commercially questionable concepts which may be deemed to negatively impact vendors - however, i believe this to be a short-sighted view...
> 
> In consideration; i consider the following,
> 
> 1. Centralisation - Brand Sites / Systems & “trust”
> In retail markets especially; loyalty relationships, broadly - the amount of information an individual is willing to hand-over to a multi-national or major brand, is arguably significantly higher - that is with less psychological barriers - than individuals providing information to SOHO (small office / home office) and SME (small to medium enterprise) operators.   Whether it be a website, or indeed some type of physical form filled out on premises - scope within Web-Payments, is online. So, we’re aiming to produce standards useful to anyone that wants to set-up a virtual ‘shop’.  
> 
> — Implicitly, loyalty relationships are different and should be treated differently to transactional relationships.  A person may have a good relationship with a local shop owner; but meet a new supermarket representative each-time they attend the retail outlet.
> 
> It is likely that Interpersonal relationships are better with smaller retailers / businesses - than larger ones.  Yet digitally, it is likely the opposite. 
> 
> EG: In Australia, we’ve got two major grocery retail chains - both with different loyalty cards.   Many more people would create accounts with these two brands, than they would with every smaller retailer they spend their money with.   
> 
> When considering these types of retail considerations; in-turn, this effects the sale of POS systems, services offered by POS systems, whether the smaller retailer needs to pay some 3rd party $$$PCM to operate a ‘reputable loyalty service’ connected to their POS system in-order to gain market-acceptance, consumer trust, etc.   POS Systems in Australia (similarly to the rest of the world i imagine) are often produced by small, specialised software development companies who specialise in the local taxation law, the industry requirements (hairdressers, hardware, trades, cinema, fruit and veg shops, general practice/medical, etc.) and as such the means in which they connect to web-services needs to be as simple as possible. 
> 
> Other forms of ‘digital asset’ businesses would also suffer if these ‘declarations’ were not definable.  An example that comes to mind, would be historical societies / groups, who have collections of images and historical content - good for researching you descendants.  If a sense of safety in providing details to these organisations were definable, then both parties may benefit more greatly.  Other constituents of the specification potentially support use-cases, such as free use of heritage Content for educational purposes whilst transmitting some form of offer statement that could be integrated with a commercial printers POS / Printing system - to include a fee and transactional function, for printing some historical image (for example) for a paying customer (in that case, adding to the fee made payable for the print product / service to include an effective copyright fee); however these functions do not take into account the ‘loyalty’ relationships or any form of agreements surrounding the identity information of the end-customer. 
> 
> I note; the implications are broader than simply buying a bottle of soft-drink; but also, pharmacy and other medical industry uses, etc.  These types of organisations require / demand trust structures, yet describing the purpose of furnishing information to these providers does not appear to be provided as yet.
> 
> So; Whilst larger enterprises with sophisticated brand and technology infrastructure solutions - provided on either a retail (i.e.: apple store) or wholesale (i.e. shopify) basis does enhance a consumer sense of ‘trust’ over alternative systems developed DIY (i.e.: wordpress).  Systems such  as PayPal do improve these ‘trust’ layers; yet when comparing these sociological systems / software defined solutions - an array of qualities supported for other content, by creative commons (as an example) seemingly features greater functional capabilities / properties. 
> 
> In simple terms; unless the expectations are defined, it’s impossible to say whether an event breached those expectations or otherwise.  I do understand that should systems be compromised acquiring data out of db’s that has been stored in a manner that complies with a privacy agreement - could in-turn breach that agreement - however i think any reasonable person would also appreciate that these events should be treated separately, to commercial behaviours that wilfully commercially exploit user-data as a revenue driver, in a manner not understood customers / those furnishing information to the receiving entity.
> 
> 2. Technical benefits & Rule of Law
> unsolicited digital ‘traffic’ is a very well known problem.  This creates network traffic, in-turn creating unnecessary network overheads / expenditure of energy.   Beyond these forms of issues are the ‘pen test’ ramifications - http://pando.com/2013/10/26/i-challenged-hackers-to-investigate-me-and-what-they-found-out-is-chilling/ is a good article about those types of capabilities; which, for the record i have no problem with from a law-enforcement point of view but rather, the broader accessibility of such capabilities for various purpose including that of commercial purposes specifically…
> 
> The Rule of Law in most states, i think in-part as a constituent of human rights doctrine(?) have laws in place relating to privacy.  So, understanding that the holistic technical solution around enforcement is more difficult - i figure the potential scope definition might simply be to define some sort of ontological function that can be referenced (or indeed stripped) which could then be related to other systems externally produced, which could on an opt-in basis, track compliance (for example).
> 
> I also think their would be (or are) existing services that can abstract personal information - for example, using a one-time email address, or a bridged VOIP address - which isn’t actually the users direct details, as such lowering the quality of information gathered without explicit consent and/or the ability for users to manage ‘settings’.  I also imagine that should a user in the future, have appropriate tools as to manage their own domain and generate email addresses for use with specific parties only (rather than a bulk-inbox styled address scheme) the user-side of the technology equation can support additional tooling as to enhance support for privacy - which broadly, in an array of areas, is arguably a focal point of technical web-science and software/technology development broadly.
> 
> I’m thinking this email is getting long enough already.  
> 
> So, (apart from the in-line responses below) i’ve separated the functional definition to loyalty; in consideration that, information provided as a requirement for the lawful carriage of a transaction should reasonably be kept for the purpose of that transaction specifically.  Use of information provided by a ‘customer’ (‘credential provider’ participant, not sure the best language?) beyond this layer of functional and fiduciary responsibility requirements; may reasonably be deemed loyalty information (which may or may not include software updates, warrantee fulfilment, etc.); as such, in consideration - perhaps our use-cases, definitions, functional qualities should also separate these two areas in a clear manner free from ambiguity, and that declaring a privacy expectation by some means is both useful and supportive of defining a more robust solution overall.
> 
> Elements of the spec are distributed. So, the traditional mechanism of logging into a site with a relational DB; providing details to that site specifically for facilitating a transaction and obtaining a ‘viewport’ of any information relating to that interaction - is a functionally different quality to the opportunities made available by the web-payments spec, and related technologies.
> 
> So i’m trying to be holistic about the considerations. 
> 
> We can seek to uphold the spirit of the law; but we can’t enforce it.  IMHO, a constituent of our role, as participants of this spec is to come-up with meaningful solutions to problems people readily experience within our domain of expertise.  To Scope - for web-payments, I imagine the use-case would be to support the declaration of a privacy request or policy in relation to furnishing a merchant with personal information.   
> 
> And perhaps; a declarative definition around what is loyalty information and what is transactional information.  
> 
> I hope i’ve babbled on enough by now.  :)
> 
> TIM.H.
> 
> On 2 Jul 2014, at 11:44 pm, Brent Shambaugh <brent.shambaugh@gmail.com> wrote:
> 
>> Creative Commons Rights Expression Language (licenses in RDF)
>> 
>> http://wiki.creativecommons.org/images/d/d6/Ccrel-1.0.pdf
>> 
> 
> I believe their is a distinction between what would be considered ‘content’ (i.e. an image, document, motion image, audio, software etc.) and the definition given to information relating to the legal representation of a person (i.e. mailing address, phone numbers, email addresses, birthdays, bank account details, social-graph, weblogs, etc.); which for the purpose of transactions forms two constituents, 
> 
> 1. The capacity to fulfil a transaction
> 2. Loyalty relationships.
> 
> The latter might be considered ‘metadata’ although I believe in some forum the arguments around what metadata is; defines metadata as the tag, rather than the content or ‘value' held within the tag; yet, i think perhaps this is still ambiguous for many...
> 
> My concern about using creative commons in its current state (without enhancement / adaption) would be that CC is designed for content not privacy. 
> 
>> -Brent Shambaugh
>> 
>> Website: bshambaugh.org
>> 
>> 
>> On Wed, Jul 2, 2014 at 8:32 AM, Brent Shambaugh <brent.shambaugh@gmail.com> wrote:
>> Tim,
>> 
>> I'll admit to being a bit confused. Here is at least what comes to mind for this area.
>> 
>> Have you studied Hollenbach's work? He developed a widget library for privacy aware policy using ACL, WebID, and FOAF. 
>> 
>> http://dig.csail.mit.edu/2010/rdf-widgets/thesis.pdf
>> 
> 
> I’ve followed / researched PAW in past, haven’t reviewed the document provided above but understand their is a large amount of literature about it generally i.e.: [1].   I called Renato (his based in brisbane / AU) getting some interpretation of the background, etc.  It seems Renato has some particular experience in the E-Health Sector, which is of course a territory that features an array of sophisticated requirements in-order to support the well-being of people, broadly.
>   
>> In terms of granularity of access, I believe that they did not allow permissions on particular triples, but on documents containing them.
>> 
>> Also see more about ACL and RDF by Hollenbach here:
>> 
>> http://dig.csail.mit.edu/2009/Papers/ISWC/rdf-access-control/paper.pdf
>> 
>> In addition, see SPARQL/Update, which is an update language for RDF graphs.
>> 
>> http://www.w3.org/TR/sparql11-update/
>> 
> 
> :)  i think you’ve missed the concept.  
> 
> In the teleconf. we discussed the idea of how to create a policy orientated mechanism - inclusive of the difficulties of enforceability, being that once something has sent data to a relational DB it’s impossible to ‘demand’ that data be removed as to uphold a policy context; should the DB administrator refuse to fulfil this request.  However; this technical issue does not persist to the use-case of declaring a privacy preference when furnishing the merchant with information for a specified context.  Therein, this is not an access control concept; but rather, a metadata concept of removing the ambiguity surrounding how, why and for what purpose parties furnish 3rd parties with personal information.
> 
> More broadly; the basis for the consideration surrounds a concept i believe best entitled ‘knowledge capital’.  a link providing some definition is http://www.investopedia.com/terms/k/knowledge-capital.asp however this description does focus on its use within an incorporated legal entity rather than that of a natural legal entity (understanding that in whatever business case it is used, natural legal entities are the producers of this ‘intangible asset’).  
> 
>> A broad overview is here:
>> 
>> http://www.w3.org/DesignIssues/CloudStorage.html 
>> 
>> The last link you linked to. 
>> 
>> -Brent Shambaugh
>> 
>> Website: bshambaugh.org
>> 
>> 
>> On Wed, Jul 2, 2014 at 1:17 AM, Tim Holborn <timothy.holborn@gmail.com> wrote:
>> Nice.
>> 
>> Thankyou for the heads-up… 
>> 
>> MANU: your views / please review? 
>> 
>> On 2 Jul 2014, at 3:50 pm, Renato Iannella <ri@semanticidentity.com> wrote:
>> 
>>> 
>>> On 1 Jul 2014, at 18:13, Timothy Holborn <timothy.holborn@gmail.com> wrote:
>>> 
>>>> 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 W3C ODRL Community [1] has developed such a "permission" language (actually a Policy Ontology [2] ) which could address the use cases your outlined as its model [3] has been developed specifically for this purpose.
>>> 
>>> 
>>> Cheers...
>>> Renato Iannella
>>> Semantic Identity
>>> http://semanticidentity.com
>>> Mobile: +61 4 1313 2206
>>> 
>>> [1] http://www.w3.org/community/odrl/
>>> [2] http://www.w3.org/ns/odrl/2/
>>> [3] http://www.w3.org/community/odrl/work/2-0-core-model-constraint-draft-changes/
>>> 
>>> 
>> 
>> 
>> 
> 
> [1] http://www.w3.org/2004/09/Policy-Aware-Web-acl.pdf