Re: Musings on resource grouping

Thanks very much for setting this out, Andrea.

During yesterday's call I was trying to be as neutral as I could (it's 
the chair thing!) but on the list I'm going to be more partisan.

Things I like about this:
  - it makes use of an existing rule language and works on existing, 
freely available software.
  - This suggests that when the Rule Interchange Format Group [1] 
completes its work we'll be able fairly easily to switch over to using 
that (assuming they don't obviate the need for this by producing a 
Recommendation that says "use N3 Rules"!)
  - It's more semantic web friendly than, what I call, the "data based 
approach" (i.e. my original posting in this thread).
  - You've looked at the problem afresh and come up with a cracking good 
alternative to the preconceived ideas. That's how breakthroughs are made.

Things I don't like about this:
  - it uses a non-standardised rules language (despite its pedigree - 
TimBL and DanC - N3 has not been through a standardisation process - 
that's what the RIF is for).
  - that means we would effectively be recommending Cwm or Euler as 
these are the inference engines that use N3. Yes, anyone can build an 
RDF reasoner that uses N3, but this is quite rare. Neither of the big 2 
RDF toolkits, Redland [2] and Jena [3], seems to support N3 Rules. 
Better, I think, to specify the structure and semantics of the data and 
leave the implementation open.

Also I think there is a fundamental conflict of design ethos here. RDF 
is about triples (I know you know but this is a public discussion). 
Because the triples are anchored in URIs, they can be anywhere, agents 
can pick up the triples and process them and make sense of them readily. 
In other words, it's an open architecture. POWDER differs firstly in 
that we wish to make statements about lots of resources at once - that's 
the biggest conflict - and we want to take steps to lock things down at 
least a little so that provenance/attribution is explicit and can be 
authenticated.

In the work we've done up to now in Quatro and elsewhere, we have met 
resistance from people who are unconvinced about the semantic web - 
"it's a solution looking for a problem" and all that. I'm up there on 
the platform to say they're wrong and should recognise what it can do, 
but I think if we propose a system based on a specific rule language, 
itself based on RDF, implemented in a handful of pieces of software 
written largely by the same people (no matter how esteemed and respected 
those people are) then I think we'll "up the anti" significantly. That 
is, we'll increase resistance to take up substantially.

What I would prefer is an approach that sets out the data and its 
semantics *and* shows how existing rule languages and query languages 
can be used to interpret it.

As you know, Andrea, Dan Connolly did some work on matching data and 
users [4]. He used Cwm to process the data and match the user with the 
resource but the actual label (description) was expressed in a similar 
fashion to the data based approach. That is, he did use an off-shelf RDF 
reasoner to process the data. The Quatro proxy [5] uses SPARQL to 
extract data from RDF-Content Labels so just in those two instances we 
have different methods of using essentially the same data.

Where I think rules will *really* come into their own is when we come to 
  encode user preferences. One of the goals of POWDER is to create a 
standard (or more than one) that can replace PICS - PICSRules is part of 
that and, well, the name says it all!

My feeling is that a good standard will prescribe *just enough* so that 
the system works, without unnecessarily proscribing methods some people 
may feel comfortable with.

This is a pretty fundamental debate that I hope will trigger wider debate.

Phil.

[1] http://www.w3.org/2005/rules/wg
[2] http://librdf.org/
[3] http://jena.sourceforge.net/
[4] http://dig.csail.mit.edu/breadcrumbs/node/180
[5] http://www.quatro-project.org/TheQuatroProxy.htm

Andrea Perego wrote:
> I would bring to your attention an alternative solution to resource
> grouping wrt the one based on the DRs' scope/packages. Very simply, the
> idea is to express the constraints determining the scope of the DR
> itself by using RDF rules.
> 
> Thanks to this we can keep separate a DR and the scope of such DR. So,
> if we wish to apply to a group of resources the same DR, we just have to
>  specify a set of rules. Of course, the current WDR approach is a
> shortcut to this, but I think we'll have more flexibility using standard
> rule syntax and, in addition, we can use already existing RDF reasoners
> (such as Cwm [1] or Euler [2]) to verify whether a DR apply to a
> resource, without the need of developing further and ad hoc software
> tools. Finally, in a rule we can use any RDF/OWL vocabulary for
> expressing the conditions to be satisfied, without the need of defining
> ad hoc properties/classes.
> 
> I think I can better explain myself with an example.
> 
> Consider the strawman example at [3], reported herebelow (I use N3 [4,5]
> instead of `plain' RDF for brevity's sake):
> 
>     @prefix : <http://www.w3.org/2007/02/powder-ns#> .
>     @prefix ex: <http://example.org/vocabulary#> .
>     @prefix foa: <http://labellingauthority.example.org/foaf.rdf#> .
>     @prefix wd: <#> .
> 
>     wd:description_1     ex:property1 "value 1";
>          ex:property2 "value 2" .
> 
>     wd:description_2     ex:property3 "value 3";
>          ex:property4 "value 4" .
> 
>     wd:description_3     ex:property1 "value 1";
>          ex:property4 "value 4" .
> 
>     wd:dr_1     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_1;
>          :hasScope  [
>              a :Scope;
>              :UAstring "NOKIA";
>              :hasHost "example.org";
>              :hasURI "\\.jpg$" ];
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
>     wd:dr_2     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_2;
>          :hasScope  [
>              a :Scope;
>              :hasHost "example.org";
>              :hasPath "foo" ];
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
>     wd:dr_3     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_3;
>          :hasScope wd:primaryScope;
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
>     wd:package     a :Package;
>          :hasDRs  (
>         wd:dr_1
>         wd:dr_2
>         wd:dr_3 );
>          :hasPackageScope wd:primaryScope .
> 
>     wd:primaryScope     a :Scope;
>          :hasHost "example.org" .
> 
> 
> Now, by using rules to express the constraints determining the scope of
> each DR, we can reword the code above as follows:
> 
>     @prefix : <http://www.w3.org/2007/02/powder-ns#> .
>     @prefix ex: <http://example.org/vocabulary#> .
>     @prefix foa: <http://labellingauthority.example.org/foaf.rdf#> .
>     @prefix wd: <#> .
>     @prefix foaf:  <http://xmlns.com/foaf/0.1/> .
> 
>     wd:description_1     ex:property1 "value 1";
>          ex:property2 "value 2" .
> 
>     wd:description_2     ex:property3 "value 3";
>          ex:property4 "value 4" .
> 
>     wd:description_3     ex:property1 "value 1";
>          ex:property4 "value 4" .
> 
>     wd:dr_1     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_1;
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
>     wd:dr_2     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_2;
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
>     wd:dr_3     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_3;
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
>     {?rsc :UAstring "NOKIA";
>           :hasHost "example.org";
>           :hasURI "\\.jpg$" . }       => { wd:dr_1 :appliesTo ?rsc } .
> 
>     {?rsc :hasHost "example.org";
>           :hasPath "foo" . }          => { wd:dr_2 :appliesTo ?rsc } .
> 
>     {?rsc :hasHost "example.org" . }  => { wd:dr_3 :appliesTo ?rsc } .
> 
> 
> As you can see, DRs do not contain any more their scope, which is
> expressed by three rules (last lines), and both the package and the
> primary scope are gone.
> 
> Syntactically, a rule consists of three components: an antecedent
> (containing a set of conditions), an implication operator (=>), and a
> consequent (containing one or more statements). Both the antecedent and
> the consequent are delimited by curly brackets (
> {conditions}=>{statement(s)} ). The meaning of a rule is that, if all
> the conditions in the antecedent are satisfied, the the statement(s) in
> the consequent are true. For instance, the rule
> 
>     {?rsc :hasHost "example.org" . }  => { wd:dr_3 :appliesTo ?rsc } .
> 
> states that, if a resource (denoted by variable ?rsc) has a URL where
> the host component is "example.org", then the DR identified by wd:dr_2
> applies to it.
> 
> Now, if I access a resource with URL "http://www.example.org/foo.html"
> and we ask the reasoner to analyse the RDF file containing DRs and
> rules, it will return:
> 
>     wd:dr_2     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_2;
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
>          :appliesTo <http://www.example.org/foo.html> .
> 
> thus providing the `view' of the RDF file concerning the DR(s) applying
> to the requested resource. (Of course, the whole content of the RDF file
> can still be read by retrieving the file itself without running the
> reasoner).
> 
> The objection here may be that, if the scope is kept separate from the
> corresponding DR, anyone can publish a rule anywhere stating that, e.g.,
> wd:dr_2 applies to mysite.com. But if we suppose that DRs can be
> considered trustworthy only when valid/authenticated, we can apply the
> same approach to rules: a DR applies to a resource only if a
> valid/authentic rule states that. (By the way, Cwm has some built-in
> cryptographic functions which, maybe, can be used for this purpose [6]).
> 
> Note however that by using rules we don't have necessary to separate a
> DR from its scope. For instance, the original DR wd:dr_2
> 
>     wd:dr_2     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_2;
>          :hasScope  [
>              a :Scope;
>              :hasHost "example.org";
>              :hasPath "foo" ];
>          :validUntil "2007-09-01";
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
> 
> can be reworded as follows
> 
>     {?rsc :hasHost "example.org"; :hasPath "foo" . }
>     => { wd:dr_2     a :WDR;
>          <http://purl.org/dc/terms/issued> "2006-09-01";
>          :hasDescription wd:description_2;
>          <http://xmlns.com/foaf/0.1/maker> foa:me .
>          :appliesTo ?rsc} .
> 
> which is quite similar to the original one, but with the advantage that
> it can be processed by a RDF reasoner.
> 
> 
> Andrea
> 
> 
> 
> [1] http://www.w3.org/2000/10/swap/doc/cwm.html
> [2] http://www.agfa.com/w3c/euler/
> [3] http://www.w3.org/2007/powder/History
> [4] http://www.w3.org/DesignIssues/Notation3.html
> [5] http://www.w3.org/DesignIssues/N3Logic
> [6] http://www.w3.org/2000/10/swap/doc/Trust
> 

Received on Tuesday, 27 March 2007 15:56:04 UTC