Re: POWDER and OWL

Thanks a lot, Stasinos, for the thorough analysis you've carried out.

Before replying to specific points of your email and to its follow-ups
[1,2,3], I would like to make some general considerations which, I hope,
might turn useful.

I think that, after the new DR representation which has come out from
the Boston meeting [4], we should leave aside, for the moment,
implementation issues, and devote our first efforts in defining the
syntactically and semantically correct representation of DRs.

Although DR implementation is a key issue (and so it has always been
considered in POWDER), we can deal with it only after we reach an
agreement of the definitive and correct representation of a DR. In other
words, first we should agree on DR representation, and only afterwards
it can be modified, if possible, by taking into account how DR can be
processed.

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

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.

By contrast, RDF/OWL are both standard languages and they can express
the semantics of a DR. More precisely, they give the possibility of
expressing a statement like "IF a resource is hosted by example.org THEN
it is safe for children" in an equivalent way, i.e.: "the resources
hosted by example.org are a subset of the resources which are safe for
children."

Should we use just RDF, or we need OWL? Some components of a DR can be
expressed by using just RDF, but others need OWL. So, the answer is: we
need RDF+OWL.


Now, about the issue raised by Stasinos about DR implementation.

Stasinos pointed out a problem we considered at the beginning of POWDER,
but which has been later left aside, due to more urgent issues.

The problem is the following. We are using RDF/OWL for representing DRs.
RDF/OWL have their foundation in description logics (DL), and there
exist DL reasoners able to process RDF/OWL statements. So, in theory, we
already have applications able to process a DR. However, this is not
true, since, in a DR, the resources in the scope may be denoted by URI
patterns. The problem is that DLs have been devised to reason about
classes/individuals, and not to perform pattern matching. That is to say
that there does not exist, at the moment, a tool able to process DRs,
and that a DR parser should enforce both the features of a reasoner
(actually, a very limited subset of such features) and features of a
programming language supporting regular expressions. Something hybrid.

I'm not sure whether this is a problem. We have never assumed that tools
able to parse DRs must exist. But I'm sure that the hybrid nature of DRs
should not affect at all the decision of using RDF+OWL for representing
them, due to the considerations I've made above.

I can also add that I've considered this problem as soon as I've started
working on how DRs can be translated into rules. Now, if description
logics are not meant to perform pattern matching, this is not true in
the real world. Actually, two Semantic Web rule languages, namely, N3
and SWRL, have both built-in support for string matching and regular
expressions. In other words, it is possible to process correctly a DR by
using a reasoner supporting N3/SWRL, even though it is complex and it
may have high computational costs.

Note that I'm not saying that such reasoner should be the `official' DR
processor. POWDER is not meant to indicate an official DR parser, but
just to show their possible implementations.

At any rate, I suggest, for the moment, to leave aside implementation
issues and focus on the correct RDF/OWL representation of DRs.

Andrea

-----------
[1]http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0018.html
[2]http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0019.html
[3]http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0020.html
[4]http://www.w3.org/blog/powder/2007/11/10/summary_of_face_to_face_meeting_held_dur_2007


> From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
> To: public-powderwg@w3.org
> Cc: vangelis@iit.demokritos.gr, pnas@iit.demokritos.gr
> Subject: POWDER and OWL
> 
> Dear POWDER,
> 
> We are investigating the appropriateness of using OWL for POWDER, with
> respect to these two issues:
> 
> (a) how to represent URI groups, treated in the "powder-grouping"
>     document [1], and
> 
> (b) how to specify correspondences between a resource's falling under
>     a URI group, and this resource's carrying certain descriptors (e.g.
>     ICRA tags) and belonging to a certain class (e.g. child-safe or
>     mobileOK).
> 
> We hope that the following is going to advance the discussion and help
> today's telco.
> 
> Stasinos Konstantopoulos
> Vangelis Karkaletsis
> Pantelis Nasikas
> 
> 
> GROUPING RESOURCES
> ==================
> 
> Andrea Perego has been working on an RDF/OWL compliant representation
> of address constraints, where he defines, in OWL, a concept URI
> carrying datatype properties like wdr:hasHost, wdr:hasPort,
> wdr:hasPath, etc. These are treated as uninterpreted strings, but are
> related to Description Resources which match the URI groups against
> descriptors. Andrea has been looking into specifying a mapping of this
> OWL representation onto a SemWeb rule language, which allows RegEx
> matching. When a resource's URI matches the rule's antecedents, the
> corresponding action is fired. The action will be such, that it adds
> the appropriate descriptors to the resource [2,3].
> 
> We have also investigated a totally different approach, whereby the
> whole process is defined within OWL semantics and can be treated by a
> Description Logic reasoner, such as Pellet [4]. In this approach, the
> concepts of "Scheme", "Host", "Port", "Path" etc. are specified. A
> given URI is decomposed into its elements, and a URI instance is
> related with a Scheme instance, a Host instance, a Port instance, etc.
> 
> In this manner, URIs are broken down into ontological entities, so one
> can refer to, say, all URIs having the same host, without resorting to
> string comparisons/regex matching. URI groups are defined with OWL
> logical expressions like the one in the attachment, which corresponds
> to Example 2.2 in the powder-grouping document. A resource's belonging
> or not to a group is inferred by DL reasoning, and the descriptor
> properties that are attached to the the URI Group are automatically
> inherited by the resource.
> 
> Although it works for simple address groupings, this approach has
> several shortcomings. Firstly, the model is pretty cumbersome and
> artificial, with several inter-related (not orthogonal) relations
> (e.g. endsWithPath "foo/bar" endsWithPath "bar"), which will render
> population and maintenace of such a knowledge base difficult and
> error-prone. Note that interdependent relations cannot be inferred
> from one another, because of the limitations of DL reasoners at
> manipulating and reasoning over concrete objects (in our case, URI
> strings) as well as theoretical limitations of the OWL formalism
> itself w.r.t. defining relations (e.g., axiomatizing that that
> individual i must have relation endsWithPath "bar", if it has relation
> endsWithPath "foo/bar").
> 
> Futhermore, RegEx matching of data-property values is not supported by
> OWL, so that it is also impossible to formulate OWL descriptions of
> grouping by RegEx. As a result, we consider DL reasoning and OWL
> semantics inappropriate for inferring a resource's belonging in a URI
> group. An alternative approach to be explored, similar to Andrea's
> original approach, is to embed SWRL rules in the knowlegde base, that
> will "transfer" descriptors from a DR to a resource, when the
> necessary conditions are met.
> 
> SRWL rules are represented as instances of a sub-ontology that is
> stored in the KB, but not related or linked to the main ontology. The
> instances are used by rule engines that are invoked after each update
> of the KB to infer new facts. These new facts are explicitly written
> back in the KB, so that they can be accessed by the DL reasoner. The
> Protege library provides all the necessary tools for managing an OWL
> ontology, using a DL reasoner to infer implicit facts, and making
> these facts available to ontology query engines such as Jena. A
> different tool is required in order to invoke a SWRL rule engine to
> infer facts and write them back to the OWL KB before the DL is
> invoked. There is a vast array or rule engines available, and Protege
> provides a SWRL Bridge [6] mechanism for facilitating this procedure,
> but only provides the "translation" from the OWL represenation of SWRL
> to the native represenation of Jess [7], a commercially sold SWRL rule
> engine.
> 
> Consider, for example, the simple ontology attached (example3.owl).
> URIGroupDefinitionByRegEx g has a string property which is the pattern
> to be matched. When the pattern matches, a new relation is drawn
> between the URI group g and the resource r:
> 
> IF ResourceClassification(?r) AND resourceURI(?r, ?u) AND
> ByRegEx(?g) AND regEx(?g, ?re) AND swrlb:matches(?u, ?re)
> THEN subsumesURI(?g, ?r)
> 
> where swrlb:matches() is a SWRL built-in which performed the actual
> pattern matching. Note that ResourceClassification instances couple
> resources with a time-point (the time when the resource was
> classified), since DRs (and hence classifications based on then) have
> a limited lifetime. A second rule is necessary to make the actual
> transfer of propoerties to matching resources:
> 
> IF ICRAdescriptionResource( ?d ) AND
> temporal:hasValidTime(?d, ?period) AND
> ResourceClassification(?r) AND
> resourceURI(?r, ?rURI) AND temporal:hasValidTime(?r, ?day) AND
> temporal:contains(?period, ?day, temporal:Days) AND
> hasScope(?d, ?g) AND subsumesURI(?g,?rURI)  AND
> icra:nz(?d, ?v)
> THEN icra:nz(?r, ?v)
> 
> 
> 
> RESOURCE CLASSIFICATION
> =======================
> 
> Given that a resource falls under a URI group, the resource inherits a
> number of descriptors. Based on which descriptors are true for a
> resource, the resource is classified as appropriate or not. In the
> ICRA and MOK use cases, we could not identify any situations where
> resources are classified according to anything more complex than the
> presence or absence of a given descriptor. Furthermore, these
> descriptrors are typically flat labels, not participating in any
> ontological structure.
> 
> For this reason, it seems that a propositional prover is adequate for
> classifying resources, and will even be adequate if the descriptors
> were hierarchically organzed, as long no references were required to
> relations between descriptors. To give an example, consider the ICRA
> labels and a definition along of the concept of ChildSafe resources,
> like the one provided by Phil Archer in the attachment to his Nov 16th
> public-powderwg posting [5]. The relevant OWL fragment (attached),
> means:
> 
> something is ChildSafe iff:
>  it has property icra:oz with value true
> AND
>  it has property icra:vz with value true
> AND
>  it has property icra:lz with value true
> AND
>  it has property icra:sz with value true
> AND
>  it has property icra:cz with value true
> AND
>  it has property icra:nz with value true
> 
> Note that there are no relations between either the descriptors or the
> resources described, which makes this fragment expressible by
> propositional rules. Even in the presence of a hierarchy were, for
> example, "sconz" and "allz" are inferred from sz, cz, oz, and nz, the
> knowledge base:
> 
> something is in the ChildSafe class iff:
>  it is in the Allz class
> 
> something is in the Allz class iff:
>  it is in the Sconz class
> AND
>  it has property lz with value true
> AND
>  it has property vz with value true
> 
> something is in the Sconz class iff:
>  it has property oz with value true
> AND
>  it has property sz with value true
> AND
>  it has property cz with value true
> AND
>  it has property nz with value true
> 
> would still be propositional.
> 
> To give an example of a situation where DL reasoning is necessary,
> imagine that there is a wdr:linksTo property, relating resources that
> link to each other and we want to only classify something as ChildSafe
> if it only links to ChildSafe resources:
> 
> a resource is cp:ChildSafe iff:
>  it is in the Allz class
> AND
>  for all properties wdr:linksTo it has, the filler values of these
>  properties are resources that are also in the ChildSafe class.
> 
> or, a resource is MostlyChildSafe iff:
>  it is in the Allz class
> AND
>  is has up to 5 linksTo properties, the filler values of which are
>  resources that are not in the ChildSafe class.
>  (this particular statement is only expressible in OWL 1.1)
> 
> Another example would be if descriptors were hierarchized as, say,
> critical and non-critical; a possibly usefull class definition would
> then be:
> 
> hasCriticallyBadFeature relations have their range restricted to
> members of the CriticallyBad class.
> 
> hasBadFeature relations have their range restricted to members of the
> Bad class.
> 
> a resource is MostlyOK iff:
>  it has up to 0 hasCriticallyBadFeature relations
> AND
>  it has up to 3 hasBadFeature relations
> 
> which, again, requires OWL to be expressed.
> 
> The point behind this discussion is that OWL is a very expressive
> formalism, and POWDER will should provide the adequate use cases to
> justify its usage, as opposed to a simpler propositional formalism.
> 
> 
> REIFICATION
> ===========
> 
> On the other hand, there is another aspect of DRs that DLs (and OWL)
> are not expressive enough to capture, and that is the reification of
> DR assertions, so that they can become the object of other assertions.
> Again, in Phil's example2.owl [5], we read the assertion that a
> resource is ChildSafe if it belongs to the FOSIchildSafe class, which
> is a URI group:
> 
>   <owl:Class rdf:about="#FOSIchildSafe">
>     <rdfs:subClassOf rdf:ID="CSassertion" rdf:resource="#ChildSafe"/>
>   </owl:Class>
> 
> We then read that the assertion above is the object of a meta-assertion
> that specifies the authority that makes the original assertion:
> 
>   <rdf:Statement rdf:about="#CSassertion">
>     <foaf:maker rdf:resource="http://www.example.org/foaf.rdf#me"/>
>   </rdf:Statement>
> 
> which is not expressible in OWL. One possibility (already outlined
> above) is that DRs are treated as instances of a DR class, instead of
> classes of resources. In this manner, DR instances can simply have
> foaf:maker properties, just like the hasScope and
> temporal:hasValidTime properties already seen above.
> 
> 
> 
> OWL, SWIRL and Non-monotonic Reasoning
> ======================================
> 
> Specifying defaults that can be overriden in the present of explicit
> values, in an instance of non-monotonic reasoning, that is, of
> reasoning where an assertion might invalidate previous assertions.
> Neither OWL nor SWIRL semantics provide for non-monotonicity:
> Asserting a fact about a subclass that runs contrary to previously
> known facts about any of its superclass is invariably going to yield
> an inconsistent knowledge base where both facts hold at the same time.
> 
> We can think of two ways to support defaults:
> 
> (a) by using extra-logical computaional machinery, which will apply a
> different semantics than OWL to the statements in the DRs. For
> example, one might imagine that only RegEx scoping is available to
> SWRL rules, and any other grouping methods (e.g., address grouping
> with exceptions) are provided as annotations to OWL (RDF resources
> that are not in the owl: ns). Implementations that support such
> extensions are responsible for compiling such grouping descriptions
> into appropriate RegExs.
> 
> (b) by defining SWRL built-ins (which are arbitrary Java code executed
> by SWRL rules) that do the "dirty" job of retracting the default
> assertions from the KB when an exception is encountered. Using such
> built-ins invalidates all theoretical results about decidability of DL
> reasoning and DL-safe SWRL reasoning, and makes it possible to write
> non-terminating SWRL rule sets.
> 
> 
> CONCLUDING REMARKS
> ==================
> 
> The current RDF model [8] defines description of resources packages with
> attribution, scope and properties. This model is far more flexible from
> the old one (RDF-CL). The linkage between scope and properties is an RDF
> element in the graph. In the Boston meeting there has been a proposal to
> link scope and properties through OWL inheritance relationships. Some
> variations of OWL inheritance for DRs have been explored and are
> described above.
> 
> The main option we can see are the following:
> (a) we use the OWL formalism, and interpret it according to custom
>     POWDER semantics; and
> (b) we use the OWL formalism, and interpret it according to OWL-DL
>     semantics, sacrificing support for constructs not expressible in OWL;
> (c) we continue developing the current RDF formalism.
> 
> 
> 
> [1] http://www.w3.org/TR/powder-grouping/
> [2]
> http://lists.w3.org/Archives/Member/member-powderwg/2007Sep/att-0038/dr_and_rules.html
> 
> [3]
> http://lists.w3.org/Archives/Public/public-cwm-talk/2007AprJun/0002.html
> [4] http://pellet.owldl.com/
> [5] http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0013.html
> [6] http://protege.cim3.net/cgi-bin/wiki.pl?SWRLRuleEngineBridgeFAQ
> [7] http://herzberg.ca.sandia.gov/
> [8] http://www.w3.org/TR/powder-dr/

Received on Thursday, 22 November 2007 14:23:07 UTC