mobileOK vocabulary and Description Resources

I must apologise again for not being able to attend the recent face to 
face meeting. Picking up on from the minutes from that event though I'm 
more than a little relieved to be able to send this e-mail with an 
outline of how I believe Description Resources can be used to claim 
mobileOK conformance.

First the vocabulary (see attached mobileOK.rdf). This is a standalone 
RDF vocabulary and has no (direct) relation with POWDER. It's pretty 
simple. There's a load of metadata at the top about the vocabulary 
(which can be extended as required of course) and then two classes, one 
each for Basic and Pro. By making Pro a sub class of Basic the assertion 
is automatically made that all mobileOK Pro resources are also 
conformant with mobileOK Basic.

There is then a property (conformance) that links whatever the subject 
is to either of those classes. The range of mok:conformance is defined 
as being the mobileOK Basic class so it can only be used to link to that 
class or a sub class of it (like Pro).

And that's it. Anyone would be able to use this vocabulary in any 
semantic application. This includes RDFa btw which I would suggest has 
some interesting possible apps in the mobile world. For example, imagine 
you have a non-conformant HTML page but it includes links to resources 
that are mobileOK. RDFa lets you flag those up link by link:

<a href="http://example.com/good_for_mobile.html" rev="mok:conformance" 
about="http://www.w3.org/2008/06/mobileOK#Basic" />

This gives the RDF triple

<http://example.com/good_for_mobile.html> mok:conformance 
<http://www.w3.org/2008/06/mobileOK#Basic>

which has the potential for doing interesting things like sending that 
URI to a mobile device or whatever.

So let's turn to how POWDER can help. The attached XML file is a POWDER 
document that contains one Description Resource. I've repeated it below 
with line numbers for reference.

1  <powder xmlns="http://www.w3.org/2007/05/powder#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:mok="http://www.w3.org/2008/06/mobileOK#">

2    <attribution>
3      <maker src="http://authority.example.org/foaf.rdf#me" />
4      <issued>2008-06-25T00:00:00</issued>
5      <supportedby>http://validator.w3.org/mobile/</supportedby>
6    </attribution>

7    <dr>
8      <iriset>
9        <includehosts>example.com</includehosts>
10     </iriset>

11     <descriptorset>
12       <mok:conformance
             rdf:resource="http://www.w3.org/2008/06/mobileOK#Basic" />
13       <displaytext>The example.com website conforms to mobileOK
                       Basic</displaytext>
14       <displayicon
              src="http://www.w3.org/ICONS/mobileOK-basic.png" />
15     </descriptorset>
16   </dr>

17 </powder>

Line 1 - the root element is in the POWDER namespace. This is important 
as there's a GRDDL transform [1] associated with this that will, if 
executed, turn this into what we call Semantic POWDER or POWDER-S. Then 
we just need 2 other namespaces, the mobileOK one and the main RDF one.

The attribution block, lines 2 - 6, I hope are straightforward enough. 
Semantic Web folk will recognise the term maker as being a FOAF [2] term 
(in POWDER-S this becomes explicit) and links to a Friend of A Friend 
file that contains information about the person or organisation that is 
making the claim. A simple example of a FOAF file can be seen at [3] 
(note to self, I really must update this!). The attribution element and 
the maker element are mandatory for all POWDER documents (everything 
else in the attribution section is optional). It is permissible to put 
the FOAF data directly in the POWDER doc but any organisation creating 
lots of POWDER files will want to store their ID in a central location.

Line 4, issued, tells you when the claim was made.

Line 5 (supportedby) links to some external source of data that can be 
called upon to back up the claim made by the document. In this case it 
points to the mobileOK Basic checker.

The Description Resource (DR) itself spans lines 7 to 16. Within it, the 
IRI set is that most POWDER-ish of all things, the scope of the 
description. In this case, it's everything on example.com or, more 
formally, all resources identified by an IRI that has a host in which 
the last two components exactly match example.com. This is as simple as 
an IRI set gets. I won't go into a lot of detail here but basically the 
scope of a DR can be arbitrarily complex. As a brief example - if you 
want to describe the /mobile section of example.com and example.org as 
being mobileOK, you'd make the IRI set like this:

<iriset>
   <includehosts>example.com example.org</includehosts>
   <includepathstartswith>/mobile</includepathstartswith>
</iriset>

Then we get to the actual description of all those resources which, 
surprise surprise here, is that they conform to mobileOK Basic. This is 
done using RDF constructs. A DR's descriptor set can also include text 
that is suitable for display to end users, and it can include a link to 
some sort of logo (the URI shown in line 14 is made up of course, I 
don't know the one for the actual mobileOK Basic logo).

As for writing this up, the scheme document needs to include the 
vocabulary and perhaps an example of a DR claiming conformance. The 
example above, however, is very likely to be included in one of the 
POWDER normative documents (it's a good example of the supprtedby 
property).

As Kai reported to the group at the f2f, there should be a load of 
documents entering the public domain in the next day or so with one more 
next week (the Test Suite) at FPWD all being well. The plan is to make a 
Last Call announcement on our main normative documents after next 
Monday's meeting. I'll let this group know when the right documents are 
in the right place for review.

Phil.


[1] http://www.w3.org/TR/grddl/
[2] http://xmlns.com/foaf/spec/
[3] http://www.icra.org/icra.rdf