W3C home > Mailing lists > Public > public-powderwg@w3.org > March 2007

Re: Musings on resource grouping

From: Andrea Perego <andrea.perego@uninsubria.it>
Date: Wed, 28 Mar 2007 09:36:22 +0200
Message-ID: <460A1AF6.4050605@uninsubria.it>
CC: Public POWDER <public-powderwg@w3.org>

I see your point, Phil (by the way, thanks for this explanation, which
makes clearer to me the choices made when defining the WDR vocabulary).

I completely agree that, if we have to use a rule language, we should
use a standard one. Also, we cannot oblige people to use specific tools.
Actually, I didn't mean that N3 (and Cwm) was the right choice: I used
it as an example, since it is a working RDF rule language and reasoners
exist for it.

However, leaving aside the `explicit' use of rules (which, as you say,
may be applied when specifying users' preferences), I think that it
might be relevant to POWDER the fact itself that DRs and their scope are
semantically equivalent to rules. This means that there exists a
semantic interoperability between (a subset of) the WDR vocabulary and
any (RDF) rule language, an interoperability which can be enforced by
including in the definition of the wdr:WDR class and its properties
statements saying that they are equivalent to the components of a rule.

For instance, if a DR is structured as follows:

<wdr:WDR ...>
  <wdr:attribution>
    ...
  </wdr:attribution>
  <wdr:hasScope>
    ...
  </wdr:hasScope>
</wdr:WDR>

we can state in the WDR vocabulary (or also elsewhere) that the
wdr:hasScope stuff corresponds to the antecedent of a rule, the
wdr:attribution stuff corresponds to the consequent of a rule, whereas
the wdr:WDR corresponds to the implication operator. Note that I
slightly modified the structure of a DR, which does not have a
wdr:attribution property, only to make clearer the example. I think that
it should be possible to map a DR into a rule without any modification
of its structure (actually, I have to check this).

Note that this mapping is completely transparent to end users: DRs are
expressed according to the "data-based approach" (no Semantic Web
stuff), but they can still be processed by an RDF reasoner (no matter
which reasoner). Besides establishing a strong link with RIF, this will
make people free to use the tools they prefer (SPARQL or reasoners).

Andrea


Phil Archer wrote:
> 
> 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 Wednesday, 28 March 2007 07:33:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:11 GMT