Re: POWDER and OWL

As I said on the call, thank you very much Stasinos and all for doing 
this big chunk of work, it really is very helpful.

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
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)

So here we have something that is fully expressive and, I think, we can 
add attribution data to this so that we'd know who it was that was 
publishing the rule (?).

But: where's the input data for this? We'd need to know a lot things 
before we could process such a rule wouldn't we??? From my perspective, 
POWDER is about publishing the data that can be fed into such a rule. 
And even this rule isn't the end of the process. It might tell us that a 
given resource has or doesn't have the property 'icra:nz true' but we 
still need to do more to know what to do with this information.

This rule set feels to me like a template or a profile. "If you find out 
that the resource the user has requested has these properties: do this". 
What we need to do is to publish what the properties are so that rules, 
can be applied. Such rules would most likely be created independently of 
the DR or the content it describes.

I can only go back to my e-mail of last week [1]. This posits the 
creation of a primitive class to represent the set of all things in the 
universe that are 'child safe'. Then there is a class that represents 
the set of all things on fosi.org except those on fosi.org/associates. 
It's done using datatype properties so you can't do reasoning with them 
directly but the data is consistent and will not lead to false 
conclusions (this is its key benefit over the previous model).

What we'd then need, I think, is a profile/template/set of rules that 
says "if the resource is not child safe, redirect the request <here>" - 
that's something that can be done using SWRL or whatever, but it seems 
one step removed from questions about how we publish the Description 
Resource in the first place. As long as I have the data that I can feed 
into a rule, I'm happy.

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?

Phil.

[1] http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0013.html



Phil Archer wrote:
> Stasinos tried to send this to the public list earlier. It may yet 
> appear but I'm forwarding it now in case of difficulties so we can have 
> the maximum time to review it before the meeting later today.
> 
> Cheers
> 
> Phil.
> 
> 
> 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/
> 
> 
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Register now for the first, annual Family Online Safety Institute 
Conference and Exhibition, December 6th, 2007, Washington, DC.

Go to: http://www.fosi.org/conference2007/ today!

Received on Monday, 19 November 2007 17:50:14 UTC