Re: modelling URI groups

Hi all,

Note - this e-mail only makes sense in the context of the result of our 
face to face meeting last week. See the blog entry [1] for details.

Our colleagues at NCSR in Athens are working on the new POWDER model and 
will be circulating their results soon - and, unlike me, they _do_ have 
a background in Description Logic, OWL etc! But I want make an initial 
contribution to the conversation by reporting on some experiments I've 
been carrying out this week.

Rather than work too much in the abstract, I've taken my own 
organisation's website as a real-world example [2]. Although the content 
is all child-friendly for the most part, we do have several Associate 
Members with content that is unlikely to be seen as child friendly by 
most parents. Hence we need two DRs - one for fosi.org in general and 
one specifically for the section where the path begins with 'associates'.

As a shorthand, I've created two primitive classes (that is, open world 
classes with a potentially infinite number of instances): one is called 
'Child Safe' and the other is 'Not Child Safe'. For this example only, 
I'm taking Child Safe to mean that it has all the 'None of the above' 
descriptors from the ICRA vocabulary [3]. Not Child Safe means the same 
descriptors are set to false (there's more to the ICRA vocabulary than 
that but it'll do for this exercise). These two classes are disjoint.

If I understand my DL, these classes simply say that if a resource is to 
be considered an instance of the class of Child Safe things then it's a 
necessary condition that _if_ they have the relevant ICRA descriptors, 
they must be true. It is not, however, true, that this is sufficient to 
make it child safe.

I then created two more classes. FOSIchildSafe has the necessary and 
sufficient condition that the includeHost property has a value of 
'fosi.org' and that the pathStartsWith property does _not_ have a value 
of 'associates'.

This is disjoint with the FOSIassociates class for which the same value 
of includeHost is given and the pathStartsWith must be 'associates'.

Both includeHost and pathStartsWith are functional properties so there 
can only be one value for each (does that mean a cardinality of 1 or is 
that something else, I'm not sure??)

I'm pretty sure that these are not 'defined' in the Description Logic 
sense. That is, I believe that it means that if a resource has a URI 
that includes a host of 'fosi.org' and a path that starts with 
'associates' then, because the restrictions are necessary and 
sufficient, the resource can be said to be an instance of the class. 
However... because you can't close an axiom that uses datatype 
properties, it could be that a resource that does not have a URI with a 
host of 'fosi.org' and does not have a path starting with 'associates' 
would still be an instance of the class.

Does this matter?

POWDER is concerned with describing information resources - that is, 
things you can get over the Internet (and I mean Internet, not just 
Web). Our current Grouping of Resources doc [4] makes it clear that we 
plan to allow the definition of a set of described resources with 
reference to their IP address - but have we missed anything?

I suppose my (sadly empty) tea cup, is also an instance of the class of 
FOSIassociate since it has no host and no path - but, well, is that a 
problem for us?

Both FOSIchildSafe and FOSIassociates are then made a sub class of Child 
Safe and Not Child Safe respectively. I've using Protégé to create the 
ontology here but it doesn't have a graphical way of doing this so I did 
it by hand. Importantly for POWDER, I also included some RDF reification.

The triple

<#FOSIchildSafe> rdfs:subClassOf <#ChildSafe>

is given in ID (of 'CSassertion'). There is then a reification statement 
to the effect that the CSassertion was made by 'me' (using the 
foaf:maker property). Thus we have a way to explicitly say who it is 
that asserts that everything on fosi.org except anything with a path 
that starts with 'associates' is child safe.

Hooking Protégé up with the Pellet Reasoner [6] allows the inferences to 
become explicit - i.e. that the ICRA descriptors are all true of 
instances of the class FOSIchildSafe.

The reification side of things is not part of the OWL world - that's OK. 
POWDER is POWDER, not OWL or indeed RDF. We just use those technologies 
to achieve what we want. However, unlike the original model, OWL-based 
Description Resources are valid and consistent; We're not 'breaking the 
Semantic Web'.

Processing a DR will still require a specialised processor, one that can 
split up a URI and match it against things like host name, path 
components and so on, but those boundaries are well understood.

Incidentally, I can already hear the cry about wanting to provide 
regular expressions and strings as values for OWL restrictions and why 
this is a terrible sin. I will take it upon myself to post some comments 
on why, in the real world of content providers, this is 100% essential.

To try and test the boundaries of the model a little, I've also created 
some more classes that say that everything on fosi.org/mobile is 
disjoint with everything else on that noble domain. The mobile section 
being made a sub class of mobileOK Basic. Pellet doesn't throw up any 
inconsistencies (although it does make it plain that it doesn't know 
what to do with the data).

One thing I don't like about this model is that I had to include the 
condition 'and not pathStartsWith associates' in the FOSIchildSafe 
class. This is a pain - I wanted to be able to say 'everything on 
fosi.org is child safe unless I tell you otherwise'. I tried creating a 
disjoint exceptions class and then creating a sub class of that to cover 
the associates section but I couldn't make it work. It means that DRs 
really will have to be written by machines, not people. OK - we have a 
'get out of gaol free card' on that one - the XML model of the RDF/OWL 
model.

Phil.

[1] 
http://www.w3.org/blog/powder/2007/11/10/summary_of_face_to_face_meeting_held_dur_2007
[2] http://www.fosi.org/
[3] http://www.icra.org/vocabulary/
[4] http://www.w3.org/TR/2007/WD-powder-grouping-20071031/
[5] http://protege.stanford.edu/
[6] http://pellet.owldl.org/