Re: ACTION-541: MobileOK Scheme Document - Feedback on Kai's original ACTION-532

Let me try and make a contribution on the POWDER front.

We're a week or so away from publishing revised POWDER docs, but in a 
sneak preview, here's what a minimal self-claimed mobileOK Basic DR 
might look like:

1  <?xml version="1.0"?>
2  <POWDER xmlns=""
3    <attribution>
4      <maker></maker>
5    </attribution>

6    <DR>
7      <URISet>
8        <includeHosts></includeHosts>
9      </URISet>

10     <Descriptors rdf:resource="" />
11   </DR>
12 </POWDER>

So this says that the person or entity described at claims that everything on 
conforms to mobileOK Basic.

The data at the mobileOK URI quoted in line 10 will look something like 

<Descriptors xml:id="Basic">
   <displayText>By conforming to mobileOK Basic, the
     content provider has taken basic steps to provide a functional
     user experience on mobile devices</displayText>

And this block of data will be attributed to W3C. That's important, I 
think - W3C defines what mobileOK means, it is for others to claim 
conformance to it.

Now... there are indeed mechanisms in POWDER to enhance such a claim. 
The attribution element (lines 3-5) is mandatory for all POWDER docs as 
is its maker element so there's the first mechanism for third party 
labelling. Anyone can claim that anything is mobileOK and publish a DR 
saying so, whether they are the CP or not. But you can add in other 
stuff, one of which will be 'certifiedBy' - so that would be a link to a 
certification body. You can also have 'supportedBy' which links to some 
external data source to back up your claim, such as a test result 
document from a checker. Issue dates can also be included so if the 
checker evolves, it will be possible to see when the test was carried 
out and make an assessment accordingly. It's very open (deliberately), 
but there is no way to encode actual trust - all POWDER can do is to 
make it easy to encode the data on which an individual can assess the 
trustworthiness of a DR.

And yes, it's the DR that is the claim of conformance, the icon is just 
a human-perceivable representation of it. There's no way to stop people 
putting the icon on their pages, but it should be ignored by machines. 
You can't reliably machine test for the presence of a given image either 
- OK, you can look at the file name and/or take a hash of the MOK icons 
and check for equivalence but people might crop the logo, change the 
colour or whatever, so it's a human test to see if a mobileOK logo is 
included where it shouldn't be.

The scheme document, as I see it, will set out this operational aspect, 
a kind of "how to claim mobileOK". This could perhaps be the namespace 
document for the mobileOK vocabulary as well.


Jo Rabin wrote:
> Hi
> As mentioned in my earlier post on this ACTION I am worried that we are
> building something too complex for anyone to be bothered with - may be
> time for a grass roots review.
> Comments in line.
> Jo
>> -----Original Message-----
>> From: []
> On
>> Behalf Of Scheppe, Kai-Dietrich
>> Sent: 02 August 2007 10:01
>> To: Mobile Web Best Practices Working Group WG
>> Subject: ACTION-532: to draft mobileOK usage rules and come back to
> the
>> group
>> Hello,
>> I have taken on the above action to outline the usage rules for
>> mobileOK.
>> It turns out that usage hinges upon all sorts of things I have tried
> to
>> bring together here.
>> I would appreciate some detailed feedback.
>> -- Kai
>> I am introducing a new concept of shared labels.
>> With the increasing popularity of social networks it seems likely to
> me
>> that such labels could be shared within a community, meaning
> information
>> about them passed along.  Such a label would have an incredibly high
>> level of trust.
>> The concept is not essential to the mobileOK usage and can be excised
>> anytime, if it is not deemed realistic or important.
>> I just added it because it occurred to me.
> I'm not clear of the meaning of this, is it basically a third party
> claim? Also how would it work with the current definition of POWDER?
>> I have made the following assumptions:
>> -------------------------------------
>> - the visual part will be a logo
> I think my point would be that the logo doesn't constitute a claim, it
> is a representation that a claim is present. Like in a set of search
> results a logo may indicate that the content provider made a claim, or
> might indicate that the search engine makes a claim on the content's
> behalf.
>> - the maschine-readable part will be a POWDER description resource
>> - both will be provided by the W3C in a template like form
>> - content author and content provider are most likely different people
>> or even institutions.  Here I will speak of the content author, for
>> simplicities sake.
> I'm not sure I follow that reasoning. Or what the definitions are.
> Surely it can only be the content provider that makes a claim as it is
> them that is responsible for the format in which the content is
> ultimately served?
>> - a content author will go from self-labeling through certified
> labeling
>> to shared labeling
> As above
>> Concepts of labeling:
>> ---------------------
>> - The primary means of labeling is self-labeling.
>>   This means the content author makes the claim that his content will
>> conform to the best practices guidelines.
> I think it's the CP who is responsible.
>> - The secondary means of labeling is third party labeling.
>>   This could be by some other person or institution, without any
> further
>> wish to do anything else.
> I am a bit confused as to how you'd know about a third party claim, as
> that claim would not necessarily be indicated by retrieving the
> resource.
>>   This could also be a certification authority which provides such a
>> label as part of its service.  If this label is held by the CA itself
> or
>> provided to the author will be dealt with later in the document.
>> Concepts of trust:
>> ------------------
>> - Trust is a personal issue
>>   A user will have to decide if trust is given to a content author.
>>   A user will have to decide which certification authority trust is
>> given to, because some tests are highly subjective.
>> - Self-labeling has a variable, but low level of trust.
>>   A self-label is nothing more than a claim.
>>   A large content provider may enjoy a higher level of implicit trust
>> than a private person.
>> - Certified labels have a much higher level of trust, as an
> independent
>> party has examined and verified the claims made by the content author.
> I'm hoping that this is all part of POWDER - certified DRs that is.
>> - Shared labels, across social networks, have the highest level of
>> trust, as a much larger group of users has vested interest in those
>> labels and increases their value by providing trust across a network.
> Again I am unsure what this means and whether such usage is accommodated
> by POWDER.
>> Types of labels and trustmarks:
>> -------------------------------
>> There are two levels of mobileOK
>>   - mobileOK Basic
>>   - mobileOK Pro
>> For each level there two varieties of label
>>   - a visual label, called a logo hereafter
>>   - a machine-readable label, called a description resource hereafter
> As above, I don't think the logo is a claim, per se.
>> Therefore there are 4 labels
>> Each of these labels may carry a certification with it or not.
>> By adding certification we add trust, thereby creating a trustmark.
>> Therefore there are additional 4 trustmarks.
> Think we need to be clear what we mean by a trustmark. Does this mean a
> certified label?
>> Origin and modification:
>> ------------------------
>> Labels and Trustmarks are provided by the W3C according the
>> Recommendations produced by the Mobile Web Initiative Best Practices
>> Working Group (MWI BPWG) and POWDER working group.  They can be
>> downloaded at [insert appropriate URI here]
>> Only those labels and trustmark may be used.
>> The values, for example links and references, may be modified to
> provide
>> the information necessary.
>> The data structure of a description resource, may be extended, as in
>> adding a validuntil date, but must not be reduced.
>> The W3C is not a certification authority.
>> There are companies who provide these services and may utilize the W3C
>> labels and trustmarks.
> Surely the DR can't be one-size-fits-all as it makes reference to the
> content the claim is in respect of, when the claim is made, by whom,
> etc.?
>> Conformance:
>> ------------
>> mobileOK Basic is achieved if a given web page has passed all tests of
>> the W3C based mobileOK checker, found at
>> mobileOK Pro is achieved if a given web page has passed all tests
>> defined in the mobileOK Pro Tests document, found at
>> 0716
> This is an important point. Content is mobileOK if it passes the tests
> defined in the mobile Basic Tests document.
> Running your content through the checker is a good way of verifying that
> it does so pass the tests. The checker is only a reference checker and
> any other checker which implements the tests is just as good. Right?
> However, who checks the checkers? What does being a conforming checker
> mean? And when we alter the checker test suite because we find there is
> a bug, what does that say about checkers that don't pass the latest
> suite or indeed any verification that was carried out using the earlier
> imperfect version of the checker?
>> Warnings are informative only and do not influence passing or failing
> of
>> tests.
>> There is no partial conformance.
>> A content author may inform the public which subset of the Best
>> Practices are adhered to, but this may not be done in conjunction with
>> usage of a label or trustmark.
>> Verification of conformance:
>> ----------------------------
>> Without certification conformance is no more than a claim and claims
> can
>> be made falsely.
>> With certification trust is added to the claim and we speak of a
>> trustmark.
>> A label shared on a social network, while imbued with trust through
> the
>> network, looses this trust outside of the network.  As such, even
> within
>> a network, certified labels would be strongest in trust.
>> Certification must be done by an independent third party, that is
>> recognized as a certification authority.
>> False claims and non-conformance:
>> ---------------------------------
>> Deliberate false claims undermine the trust that is placed in a label
> or
>> trustmark.
>> As such
> "we'll nuke them" as Matt Womer is fond of saying?
> Ref the following, I'd need to review where POWDER has got to ...
>> Structure of label and trustmark:
>> ---------------------------------
>> Visual labels:
>> - a logo is a graphical representation that will possess a link to the
>> W3C mobileOK checker
>> - a trustmark will be the same graphical representation, with a
>> distinguishing difference, that links to the certificate issued and
> thus
>> also and indirectly to certification authority.
>> Machine-readable labels:
>> - a description resource must contain the following information:
>> 	* which resources or group thereof does this DR refer to
>> 	* who is the author of the resources
>> 	* from when is this DR valid
>> 	* until when is this DR valid
>> 	* what is the certification authority
>> 	* where is the certificate
>> 	* from when is the certificate valid
>> 	* until when is the certificate valid
>> 	* where are one or more black-lists of false mobileOK claims
>> 	* which level of mobileOK is being claimed
>> 	* which mobileOK checkers, in addition to the W3C checker, have
>> been used
>> Logos:
>> ------
>> Logos are graphical icons similar to those used for content that is
>> valid according to a given DTD.
>> A content author may use such a label, for each level, if he claims
>> conformance.
>> Description Resources:
>> ----------------------
>> DRs are separate RDF documents stemming originally from the POWDER
>> working group.  Please refer to the appropriate documents of the
>> working group ( to learn about
> structure
>> and usage of the DR.
>> A content author may use such a DR, for each level, if he claims
>> conformance.
>> Usage of labels and trustmarks:
>> -------------------------------
>> - Logos and DRs should be used in pairs, but may be used singly.
>> - a logo or its trustmark must refer only to the delivery context of
> one
>> URI, meaning the content that is ultimately displayed on the
> requesting
>> device's screen.
>> - a DR or its trustmark may refer to a grouping of resources, which
> must
>> be defined in the scope of the description resource.
>> - logos may be placed anywhere on a webpage, but it is recommended to
>> follow established practices and place the label in the bottom of a
> web
>> page.
>> - a DR would be identified by a <link> element which is found in the
>> header of the document in question
>> Hierarchy of labels and trustmarks:
>> -----------------------------------
>> A trustmark may replace the label.
>> Should trust be lost, through expiration or some other means, then the
>> content author must replace the trustmark with a label.
>> Should trust be regained then the label may be replaced by the
>> trustmark.

Received on Friday, 15 February 2008 17:55:04 UTC