Re: POWDER and OWL

Phil, POWDER,


On Mon Nov 19 17:50:01 2007 Phil Archer said:

> It seems to me we need to find the best compromise between two extremes:
>
> 1. Just publish the data in a simple format and tell people how to process 
> it if they want to. Whilst this would be machine-readable, it is not really 
> machine-processable in an automated, generalised environment.
>
> 2. DRs become a set of (potentially very complex) rules, something like:
>
> IF ICRAdescriptionResource( ?d ) AND
> temporal:hasValidTime(?d, ?period) AND

[snipped]


One possible compromise, to be considered by the group, is the
following: let DRs and groups be RDF resources, without trying to cast
them into OWL or any other formal semantics. The implementor is free to
choose whatever mechanism it best suited for treating the data (which
almost centrainly isn't going to be OWL or SWRL reasoning). The
implementor is responsible for guaranteeing that descriptors get copied
from DRs to the actual resources being described, whenever the DR is
applicable (is still valid and the resourse is withing the DR's scope).

OWL can then be used to classify resources as, e.g., ChildSafe,
depending on OWL properties (POWDER descriptors) that resources have or
have not. E.g.:

  <owl:Restriction>
    <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</owl:hasValue>
    <owl:onProperty>
      <owl:FunctionalProperty rdf:about="http://www.icra.org/rdfs/vocabularyv03#nz"/>
    </owl:onProperty>
  </owl:Restriction>

(fragment of example4.owl, attached).

which are AND'ed, OR'ed, etc together using OWL logical connectives like
owl:intersectionOf. Such a simple description of simply having or not
having pre-specified properties can even be hidden behind a less verbose
front-end. Where a labelling authority needs to gets their hands dirty
with OWL, is if they wish to specify more complex rules, like:

  <owl:Class rdf:ID="ChildSafeStrict">
    <owl:equivalentClass>
      <owl:Class>
        <owl:intersectionOf rdf:parseType="Collection">
          <owl:Class rdf:about="#ChildSafe"/>
          <owl:Restriction>
            <owl:onProperty>
              <owl:ObjectProperty rdf:ID="linksTo"/>
            </owl:onProperty>
            <owl:allValuesFrom rdf:resource="#ChildSafe"/>
          </owl:Restriction>
        </owl:intersectionOf>
      </owl:Class>
    </owl:equivalentClass>
  </owl:Class>

which says that ChildSafeStrict resources are:
(a) ChildSafe themselves, AND
(b) only link to ChildSafe resources.

The need for such a rule would justify resorting to as expressive a
language as OWL, but would also mean that no simpler "front-end" can be
used, as anything expressive enough will also have to be complex enough.

> On a practical note, the concept of '<foaf:maker> asserts that <Resource 
> Set> is a sub set of <description>' is intuitive and, in many cases, will 
> be able to be modelled in a simple bit of XML to which an XSLT can be 
> applied (if required) to create the OWL data.
>
> I'm missing something aren't I?

The thing is, one can always represent all kinds of relations in XML or
RDF, but not all of them are computable by DL reasoners. OWL is
computable by being careful to avoid meta-statements (among other
"computability-dangerous", but potentially useful constructs).

If you can precisely specify what it is that needs to be done with the
information in foaf:maker, it will help a lot. For example, will it be
used to simply let browsers black-list or white-list labelling
authorities? Or will it be involved in the classification, e.g.:

IF 3 or more authories say it is ChildSafe
THEN it is ReallyChildSafe

Fitting the latter in OWL is going to be really tricky, and might
require other compromises to be made. I can try to work this out, if
expressions like this are of interest to the group.

Hope this helps,
s