Re: New DRs

Hi,

Please allow me to voice some concerns, TBD at today's telco.

On Mon Nov 26 09:16:05 2007 Andrea Perego said:

> First we specify an owl:Class denoting all the resources hosted by
> example.org (i.e., the "DR's scope"):
> 
> <owl:Class rdf:ID="ResourceOnExampleDotOrg">
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&wdr;includeHost" />
>       <owl:hasValue>example.org</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
> </owl:Class>
> 
> Then we specify an owl:Class denoting all the resources which are safe
> for children (i.e., what formerly was called the "DR's descriptors"):
> 
> <owl:Class rdf:ID="ResourceSafeForChildren">
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&icra;oz" />
>       <owl:hasValue>true</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&icra;vz" />
>       <owl:hasValue>true</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
>   [... more stuff ...]
> </owl:Class>

I believe you will agree that if OWL vocabulary is used, it should be
used as prescribed by the OWL specification, rather than using the
formalism under a different semantics. Although not shown in Andrea's
example, I remember a strong POWDER desideratum of being able to express
overridable defaults. Imagine augmenting the example above with the
following, based one of Phil's examples:

<owl:Class rdf:ID="ResourceOnExampleDotOrgAssociates">
  <rdfs:subclassOf>
    <owl:intersectionOf>
      <owl:Restriction>
        <owl:onProperty rdf:resource="wdr:includeHost" />
        <owl:hasValue>example.org</owl:hasValue>
      </owl:Restriction>
      <owl:Restriction>
        <owl:onProperty rdf:resource="wdr:startsPath" />
        <owl:hasValue>associates</owl:hasValue>
      </owl:Restriction>
    </owl:intersectionOf>
  <rdfs:subclassOf>
</owl:Class>

<owl:Class rdf:ID="ResourceUnSafeForChildren">
  <rdfs:subclassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="&icra;oz" />
      <owl:hasValue>false</owl:hasValue>
    </owl:Restriction>
  <rdfs:subclassOf>
  <rdfs:subclassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="&icra;vz" />
      <owl:hasValue>false</owl:hasValue>
    </owl:Restriction>
  <rdfs:subclassOf>
  [... more stuff ...]
</owl:Class>

Making ResourceUnSafeForChildren a subclass of
ResourceOnExampleDotOrgAssociates is going to make a resource like
http://www.example.org/associates/sample/ match both classes and have
*two* instatiations of the icra:oz property, one carrying the value
"true" and one carrying the value "false".

In general, non-monotonicity (defaults and exceptions) does not fit OWL
semantics, and that has nothing to do with the computational machinery
used to infer facts from OWL knowledge bases (DL reasoners, rule
systems, or whatever) it is a feature of the semantics of OWL itself.
One can imagine an OWL-prime formalism that does included these
features, and one can also build tools to support it, but one should
also specifically say that this is a brand new species, not be confused
with what semantic web tools identify as OWL. Especially in order to
satisfy the desideratum that POWDER publishes data in a format that
won't be misunderstood by existing tools.

On a related note, on Tue Nov 20 16:59:16 2007 Phil Archer said:

> We are looking at OWL only because it appears to do what we need -
> which is to provide a method through which we can publish a definition
> of, say, 'mobileOK' and a resource set and find out that the resource
> set is mobileOK. Importantly, it allows us to publish data in a format
> that won't be misunderstood by existing tools.

This bit I am not entirely persuaded about; OWL appearing to do what
POWDER needs, that is. URI Group membership rules and attribution (in
their current form) do not fit into OWL, and that only leaves us with
the mapping between URI groups and descriptors.

This latter aspect fits into OWL, but not perfectly, as, at least
according to the current use cases, OWL is too powerful for the simple
needs of this particular mapping. POWDER still can choose to keep OWL as
part of the powder schema, as long as it is clear to POWDER that there
is a lot of expressivity left untapped. Furthermore, POWDER tools have
to realize that they might encounter complex OWL constructs, and know
how to deal with them.

> The foaf:maker attribute is critical! Without it, POWDER isn't POWDER.
>
> > IF 3 or more authories say it is ChildSafe
> > THEN it is ReallyChildSafe
>
> That's a rule that an implementor might define and use but it's beyond
> the scope of POWDER. What we're about it providing the data that can
> be used in rules, whether written in a semantically-rich environment
> or just a straightforward Boolean statement.

POWDER has to specify what kinds of constructs are supported and what
aren't. You shouldn't think of this as an implementation detail, this
is a representation issue, determining the form that DR rules take.

Supporting or not axioms like this is going to delineate the
boundaries of the expressivity required by the POWDER formalism. The
usual trade-off of simplicity vs. expressivity applies, so the more
complex things the labelling authority can say, the more demanding is
the formalism going to be on the child-protection expert writing the
rules.

> Now, about the issue raised by Stasinos about DR representation.
>
> In theory, a DR can be specified by using any suitable (knowledge
> representation) language. However, the purpose of POWDER is to provide
> specifications explaining how they can be expressed by using Web
> technologies. So, we have three options:
> - using XML
> - using RDF/OWL
> - using a Semantic Web rule language

RDF/OWL is one particular RDF schema, but not the only one. POWDER can
define another RDF schema, which is not OWL. As a matter of fact,
given the various constraints in place, it seems that POWDER can only
be some (not OWL) RDF schema.

> As a matter of fact, it has been noticed that the semantics of a DR is
> equivalent to a rule of the type "IF a resource is hosted by example.org
> THEN it is safe for children." So, rule languages should be the right
> choice. The problem is that, at the moment, there do not exist
> *standard* rule languages (N3 and SWRL are just proposals), and so we
> cannot use them.
>
> XML may be fine, but the problem is that it is meant for representing
> data structures, and cannot express the semantics of a DR.

RDF is a semantics for XML, that of sets of predicate-subject-object
triples. OWL is a semantics for RDF, that of dyadic first-order logic.
In other words:
(a) all valid RDF documents are also valid XML documents. The reverse
    is not necessarily true.
(b) all valid OWL documents are also valid RDF documents. The reverse
    is not necessarily true.

I think of POWDER as an RDF schema (specifying syntax), and a
document+reference implementation giving semantics to RDF documents that
comply to the POWDER schema. The question is whether OWL vocabulary will
be used for parts of POWDER documents.

Going back to today's email by Andrea:

> The next step concerns how we can specify that such claim has been made
> by David.
> 
> [snipped reification example and explanation]
> 
> Now, the first point is: does anybody agree that this is the correct way
> of expressing the semantics of a DR by using RDF/OWL?

Using OWL Full, as this is a second-order construct. Note that the new
OWL-1.1 specification will only allow second-order
constructs if they are treated as extra-logical annotations, and not
participate in any concept descriptions.
Quoting http://www.w3.org/Submission/owl11-overview/#2.4 :

> In OWL 1.1 a name can be used as any or all of an individual, a class,
> or a property. The computational problems that would arise if this
> were treated as in RDF are avoided by ensuring that no aspect of the
> use of the name as an individual has any effect on the meaning of the
> name as a class.

This is why I insisted on discussing what kinds of constructs foaf:maker
properties will be allowed to participate in. This is not an
implementation detail, this is crucial for determining the expressivity
of the formalism being defined.

Best,
Stasinos

Received on Monday, 26 November 2007 13:21:55 UTC