- From: Andrea Perego <andrea.perego@uninsubria.it>
- Date: Wed, 28 Mar 2007 09:36:22 +0200
- 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 UTC