W3C home > Mailing lists > Public > public-bpwg@w3.org > November 2008

Re: New draft 2008-11-10 of mobileOK Scheme

From: Phil Archer <phil@philarcher.org>
Date: Tue, 11 Nov 2008 11:02:16 +0000
Message-ID: <49196638.5010904@philarcher.org>
To: Jo Rabin <jrabin@mtld.mobi>
CC: Francois Daoust <fd@w3.org>, MWI BPWG Public <public-bpwg@w3.org>

Jo, taking your comments on board...

I've uploaded an edited version of the doc to [1] - obviously 
temporarily. In it I have:

1. Amended section 2.2.1 on RDF to firstly correct the triple (we'd 
missed off the 'Conformant' bit at the end) secondly, to add a line that 
links that section to the following one on POWDER.

Why include the RDF bit at all?

  - because it's good practice to create a human readable document that 
defines what terms in a vocabulary mean
  - because the mobileOK vocabulary states that it is defined in this 
document
  - because triple stores (RDF data sets) can describe anything, whether 
there is a link to that data or not, just as I can comment on, say, 
Barrack Obama, even though we've not met.
  - because the POWDER method described uses the vocabulary to make the 
claim.

2. Amended the POWDER example to give the correct URI of the logo.

3. Amended the text talking about HTML link to a) update the rel type 
(we're going to use describedby, not powder) and note that not all 
versions of HTML support the profile attribute (HTML5 is bent on killing 
it off).

4. Added a single line about HTTP link with an example and a link to the 
current Internet Draft.

[1] http://philarcher.org/mobileOK/20081111.html


Jo Rabin wrote:
> 
> Thanks Phil
> 
>  > 1. No, there's no linkage to the RDF - the example triple is just a
>  > triple that could occur in any RDF data set. It would be unlikely to
>  > exist on its own and you wouldn't link to it as such.
> 
> OK so I am unclear why we are telling people this information in this 
> document? Seems to be "If you want to make an abstract statement 
> unconnected to your actual content not accessible by any means described 
> in this document _and_ you want to use RDF, this is how you might do 
> it?" Sorry if this seems flippant, but seems to be probably something 
> that confuses rather than helps your average "Joe". Perhaps we should 
> remove it.
> 
>  > 2. Do you really want to omit mention of HTTP Link here?
>  > http://philarcher.org/powder/20081110.html#httplink. We plan to leave it
>  > in the document even if we end up having to flag it as informative.
> 
> No, I guess we ought to say something, but what?
> 
> Jo
> 
> On 10/11/2008 20:40, Phil Archer wrote:
>>
>>
>> Jo Rabin wrote:
>>> OK folks, here is another shot at it. Machine readable claims back in.
>>> Still needs to be aligned with the license. Some bits missing still too.
>>>
>>> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20081110
>>>
>>> I think Phil wanted to have some aspects of the POWDER stuff changed, 
>>> but regret that I can't find his email on the subject, despite 
>>> frantic Google Desktop searching.
>>
>> Jo, let me put you out of your misery:
>>
>> The example in the version you've posted was written pre-TPAC. Now 
>> that we have the URI of the logo, and now that I've put the relevant 
>> POWDER doc through the spill chucker, the example at:
>>
>> http://philarcher.org/powder/20081110.html#eg5-3
>>
>> is correct (this version of the doc has now been handed over to our 
>> team contact (Matt) for publication so this is very much a temporary 
>> URI and SHOULD NOT normally be referenced!).
>>
>> Two more things:
>>
>> 1. No, there's no linkage to the RDF - the example triple is just a 
>> triple that could occur in any RDF data set. It would be unlikely to 
>> exist on its own and you wouldn't link to it as such.
>>
>> 2. Do you really want to omit mention of HTTP Link here?
>> http://philarcher.org/powder/20081110.html#httplink. We plan to leave 
>> it in the document even if we end up having to flag it as informative.
>>
>> Apart from that, I'm happy.
>>
>> HTH
>>
>> Phil.
>>
>>>
>>> Ref Francois's comments:
>>>
>>> 1. OK
>>>
>>> 2. That's not clear to me from reading the license.
>>>
>>> 3. Think we need to in view of section 2. reading "Claiming mobileOK 
>>> ..."
>>>
>>> 4. I still don't understand why a machine testable claim needs to be 
>>> included to reveal a machine testable condition. Further, ref CT, the 
>>> claim says that a mobileOK representation is available at the URI, 
>>> not that this representation is mobileOK. So I am not clear that this 
>>> is very useful in that context either.
>>>
>>> 5. No that wasn't what I meant really. More that I think that the 
>>> world could possibly be a better place if we had a way of sites 
>>> expressing their site map and including where various sorts of mobile 
>>> content are to be found. The point being that mobileOK content is 
>>> just one sort of mobile friendly content, and you might be looking 
>>> for a more advanced experience. Per discussion on CT list we need to 
>>> develop a vocab to do that. Telling folks to put a machine readable 
>>> mobileOK claim on and then later telling them to do it in a different 
>>> way, possibly not that helpful.
>>>
>>> Jo
>>>
>>>
>>> On 07/11/2008 17:46, Francois Daoust wrote:
>>>> A couple of "IMO" thoughts:
>>>>
>>>> 1. mobileOK Scheme is to be published as a Working Group Note, so 
>>>> for once I would not worry too much about making a reference to a 
>>>> not fully existing POWDER spec.
>>>>
>>>>
>>>> 2. The license draft specifies the conditions that must be met to be 
>>>> allowed to use the trademarked "mobileOK®" string and the 
>>>> trademarked mobileOK logo to claim conformance to mobileOK. The 
>>>> claim could be made on paper, on a bus, on some other page, 
>>>> whatever. There may be other claims that don't make use of this 
>>>> trademarked material.
>>>>
>>>> In particular, there is no trademark on the machine-readable claim, 
>>>> I don't think there can be one, and I don't think that's necessary 
>>>> to be able to go after someone mis-using the 
>>>> "http://www.w3.org/2008/06/mobileOK#conformant" URI. But a legal 
>>>> view on that could be helpful.
>>>>
>>>>
>>>> 3. About using the "mobileOK®" string, I don't think it is required 
>>>> that we define it in the mobileOK Scheme document, but equally agree 
>>>> that it looks odd that all possibilities mentioned in the license do 
>>>> not show up in the mobileOK Scheme doc.
>>>>
>>>>
>>>> 4. About telling whether this will be used by anyone, I agree with 
>>>> Phil. There were some use cases listed in previous drafts. Whether 
>>>> any of them will actually be put into practice is difficult to say. 
>>>> It could be useful, which is what I think is important. I'd say we 
>>>> should stay silent on this and focus on defining ways to claim 
>>>> mobileOK conformance. It could have a direct use in the Content 
>>>> Transformation Guidelines. Plus people tend to enjoy saying they 
>>>> conform to this and that, so we'd better specify means to make this 
>>>> possible.
>>>>
>>>>
>>>> 5. about wrapping the mobileOK claim into something of more general 
>>>> utility, I understand it as referring to the "aspirational" level 
>>>> we've been talking about. I don't remember: did we ever resolve to 
>>>> drop it? I think it's, in any case, something that is distinct from 
>>>> the "real" mobileOK claim, and that it would need a different logo, 
>>>> string, and/or machine-readable assertion.
>>>>
>>>>
>>>> In short, I second Phil's proposal: i.e. the same document as the 
>>>> latest one completed with the previous sections 2.1, 2.2, 2.4 for 
>>>> the RDF vocabulary class and POWDER reference.
>>>>
>>>> Francois.
>>>>
>>>>
>>>> Jo Rabin wrote:
>>>>> On 07/11/2008 10:59, Phil Archer wrote:
>>>>>>
>>>>>>
>>>>>> Jo Rabin wrote:
>>>>>> [..]
>>>>>>
>>>>>>>
>>>>>>> I anticipate some proposed text from the Member from Suffolk 
>>>>>>> addressing re-insertion of references to machine readable claims. 
>>>>>>
>>>>>> See e-mail sent late last night: 
>>>>>> http://lists.w3.org/Archives/Public/public-bpwg/2008Nov/0010.html
>>>>>>
>>>>> Thanks! (Makes mental note to read last night's email before 
>>>>> sending out today's email)
>>>>>
>>>>>>
>>>>>>
>>>>>> Both you and he
>>>>>>> are welcome to join the little task force.
>>>>>>>
>>>>>>> In this context I need to say that the organisation I represent 
>>>>>>> has no plans to use the logo under license - so I think I have 
>>>>>>> now reached the point where I need to understand
>>>>>>> a) what the use cases are, as I mentioned above
>>>>>>> b) that this is really going to get used in some way by content 
>>>>>>> providers
>>>>>>> c) that some search engine somewhere is planning to look for 
>>>>>>> machine readable labels.
>>>>>>>
>>>>>>
>>>>>> Here's what one rather large search engine told me on a recent 
>>>>>> visit to Silicon Valley: You create the data, make sure it's not 
>>>>>> full of spam, and we'll use it. But don't expect us to make a 
>>>>>> public statement on the issue to help you on your way.
>>>>>>
>>>>>> In other words, if you want a search engine or two to make a 
>>>>>> statement about the usefulness of mobileOK, or any other 
>>>>>> machine-readable label, 
>>>>>
>>>>> I think there is a difference between mobileOK and general machine 
>>>>> readable labels. Today (and remember that things have moved on 
>>>>> since we started discussing this three and a half years ago) 
>>>>> mobileOK contains only machine testable aspects. So a search engine 
>>>>> that is truly interested in whether a site is mobile friendly is 
>>>>> likely to test it. Ours (find.mobi) does at least.
>>>>>
>>>>> To my mind this is rather different from using labels to express 
>>>>> judgements that cannot be determined by a machine other than by 
>>>>> reading the label. To me this is what labels are useful for and 
>>>>> naturally I comment your and POWDER's work in this very important 
>>>>> area.
>>>>>
>>>>> If we still had a non machine testable aspect to mobileOK then I 
>>>>> think the labelling stuff would be very useful. As things stand 
>>>>> today I think labelling is at best moot in respect of mobileOK.
>>>>>
>>>>> So far as it being used by browsers, well, from a mobile browser's 
>>>>> perspective finding a label on content it has already retrieved is 
>>>>> really all too late, isn't it?
>>>>>
>>>>> However, on this theme, I also think that labels are going to be 
>>>>> very useful indeed for labelling sites for the discovery of mobile 
>>>>> friendly content - of various kinds, where mobileOK is just one 
>>>>> very basic type of mobile friendly content. To my mind this is one 
>>>>> of the major unresolved issues to come out of the CT work, to which 
>>>>> it is also relevant. So perhaps it would be sensible to wrap the 
>>>>> mobileOK claim into something of more general utility?
>>>>>
>>>>> Jo
>>>>>
>>>>>> before you decide to use it, you'll never decide to use it. If, 
>>>>>> however, you really want search engines to have an easy way to 
>>>>>> identify mobile-friendly content, and if you want to encourage 
>>>>>> content providers along a route that ends up with more mobile 
>>>>>> friendly content that they can advertise as such, then you need to 
>>>>>> create the best platform possible for that to happen.
>>>>>>
>>>>>> It seems to me that, given the feelings expressed around this 
>>>>>> issue and the fact that, for all our best efforts, POWDER is going 
>>>>>> to be at PR, not Rec, next month, that including some examples of 
>>>>>> what you MAY do to make mOK machine-readable in this doc is a 
>>>>>> pretty basic step that we can take without upsetting the apple 
>>>>>> cart too much or creating dependencies we could do without.
>>>>>>
>>>>>> Phil.
>>>>>>
>>>>>>> I suggest that if we are to continue this work then We really 
>>>>>>> need to get to the bottom of this, with the idea that it all 
>>>>>>> needs to be sorted out by Dec 1 which is the end of review for 
>>>>>>> mobileOK Basic Tests 1.0 [MOK] (sic). Otherwise probably the 
>>>>>>> simplest thing is to drop the idea of a license and the logo till 
>>>>>>> we are clearer on it, and publish the scheme document just as a 
>>>>>>> way of linking together Best Practices, mobileOK Basic Tests 1.0 
>>>>>>> and the Checker.
>>>>>>>
>>>>>>> Sorry if I seem to be a bit fed up with this topic. But I am.
>>>>>>>
>>>>>>> Jo
>>>>>>>
>>>>>>> On 07/11/2008 09:31, Francois Daoust wrote:
>>>>>>>>
>>>>>>>> I confess I'm a bit surprised to see that the section "Claiming 
>>>>>>>> mobileOK Conformance using POWDER" was entirely removed.
>>>>>>>>
>>>>>>>> My recollection of our discussion was that:
>>>>>>>>  1. it is not mandatory to use a machine-readable claim to claim 
>>>>>>>> conformance to mobileOK
>>>>>>>>  2. people may still use the machine-readable claim, and that's 
>>>>>>>> something we still want to promote as a good practice.
>>>>>>>>
>>>>>>>> In short, I think the document should just provide several ways 
>>>>>>>> to claim conformance to mobileOK:
>>>>>>>>  - the logo
>>>>>>>>  - POWDER
>>>>>>>>  [ - and possibly RDFa although I'm not sure that's such a good 
>>>>>>>> idea since there's no way to embed such a claim in a mobileOK 
>>>>>>>> representation, leading to a pretty confusing message "Use RDFa 
>>>>>>>> to claim you're mobileOK, but not in a mobileOK page. What ?!?". ]
>>>>>>>>
>>>>>>>> Did I miss something?
>>>>>>>>
>>>>>>>> Francois.
>>>>>>>>
>>>>>>>>
>>>>>>>> Phil Archer wrote:
>>>>>>>>>
>>>>>>>>> Whilst I understand that this draft reflects the resolutions 
>>>>>>>>> taken at TPAC, I would like to propose an addition to the 
>>>>>>>>> document that at least points to the option to make the 
>>>>>>>>> mobileOK claim machine-readable as follows.
>>>>>>>>>
>>>>>>>>> 2. Further Steps
>>>>>>>>> As the previous section makes clear, the mobileOK trustmark is 
>>>>>>>>> an icon that may be included on any Web page that conforms to 
>>>>>>>>> mobileOK Basic Tests. However, it is possible to go further and 
>>>>>>>>> make the claim machine-readable using any of a number of 
>>>>>>>>> different methods, thus making mobileOK content more readily 
>>>>>>>>> discoverable. The Protocol for Web Description Resources 
>>>>>>>>> [@@POWDER] includes an example of how to do this in its 
>>>>>>>>> documentation and alternatives include RDFa and microformats 
>>>>>>>>> (@@ link to Jonathan’s work on this)
>>>>>>>>>
>>>>>>>>> Link to http://www.w3.org/TR/powder-dr/#evidence (this is due 
>>>>>>>>> to be updated w/c 10 November, see it now at 
>>>>>>>>> http://philarcher.org/powder/20081104.html#evidence
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> Phil.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jo Rabin wrote:
>>>>>>>>>>
>>>>>>>>>> Hi folks, I have updated the Editor's draft of mobileOK scheme 
>>>>>>>>>> [1] in line with the resolutions taken at the F2F. I did not 
>>>>>>>>>> put anything in the document about sticking a date in the ALT 
>>>>>>>>>> test for the trustmark as I don't recall that actually being a 
>>>>>>>>>> resolution. And anyway, I don't understand what that is 
>>>>>>>>>> supposed to represent, how you'd encode it and why it would be 
>>>>>>>>>> useful, what effect it would have on the correct use of ALT 
>>>>>>>>>> and so on.
>>>>>>>>>>
>>>>>>>>>> I'd like to close out on this by the time mobileOK Basic Tests 
>>>>>>>>>> goes to Rec (early Dec). A couple of  further things need 
>>>>>>>>>> sorting out on this:
>>>>>>>>>>
>>>>>>>>>> a) ACTION-869 - Review the mobileOK license in more details 
>>>>>>>>>> and send further questions to rigo [on Jo Rabin - due 2008-10-27]
>>>>>>>>>>
>>>>>>>>>> b) RESOLUTION: Dom, Jo and Rigo to form a subcommittee to come 
>>>>>>>>>> back with a final proposal to the group within 4 weeks 
>>>>>>>>>> following on from Rigo's current proposal.
>>>>>>>>>>
>>>>>>>>>> I'm attending to these now. Meanwhile would appreciate 
>>>>>>>>>> comments on the latest draft.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> Jo
>>>>>>>>>>
>>>>>>>>>> [1] 
>>>>>>>>>> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20081106 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
> 
> 

-- 

Please note my new e-mail address. My ICRA/FOSI e-mail addresses will 
not function after the end of November.

Phil Archer
w. http://philarcher.org/
Received on Tuesday, 11 November 2008 11:03:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC