- From: Andrea Perego <andrea.perego@uninsubria.it>
- Date: Mon, 02 Apr 2007 15:47:08 +0200
- To: Public POWDER <public-powderwg@w3.org>
I'm still working on DRs/rules mapping. However, a very preliminary
solution may be mapping DRs into rules by using a rule [sic!].
Such rule will be a nested one, and it may have the following
(simplified) form:
{?rsc a foaf:Document . ?dr a :WDR . ?dr :hasScope ?scope . } =>
{ {?rsc :satisfies ?scope . } => {?dr :appliesTo ?rsc} . } .
Now, if you have a resource <rsc_1> and a DR <dr_1> containing a scope,
a reasoner infers the following rule:
{ <rsc_1> :satisfies <_g0> . } => {<dr_1> :appliesTo <rsc_1> } .
where <_g0> is a reference to the blank node corresponding to the scope
of <dr_1>.
Note that this is just a tentative idea, which needs to be checked
thoroughly.
Andrea
Andrea Perego wrote:
> As I said, it should be possible to map a DR into a rule without any
> modification of its structure (so, without adding a :hasAttribution
> property). I'll endeavour to check this quickly.
>
> Andrea
>
>
> Phil Archer wrote:
>> Sounds like we're a long way to agreement here which is very refreshing.
>>
>> I have played with an attribution property before now as it seems
>> logical from the definition we came up with the XG of a content label
>> [1]. i.e. "A resource that contains a description, a definition of the
>> scope of the description and assertions about both the circumstances of
>> its own creation and the entity that created it". Since we have a block
>> of data for the description and one for the scope it seems logical and
>> consistent to have a block of data for the attribution. However, we need
>> to watch the semantics.
>>
>> We want
>>
>> wd:dr_1 a :WDR;
>> foaf:maker foa:me
>>
>> That is, the DR was made by the entity foa:me (strictly speaking the
>> entity that is the principle subject of foa:me). Now put in the
>> attribution block:
>>
>> wd:dr_1 a :WDR;
>> wdr:hasAttribution [
>> foaf:maker foa:me
>> ...]
>>
>> Now it is the blank node that is the subject of the triple with the
>> foa:me object. We might give that blank node a URI but even so, the same
>> thing applies. We can get around this with reification but I worry we
>> may be introducing a bit of complexity for the sake of what looks neat??
>>
>> Phil
>>
>>
>> [1] http://www.w3.org/2005/Incubator/wcl/XGR-wcl/Overview.html#gtCLabel
>>
>> Andrea Perego wrote:
>>> 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 Monday, 2 April 2007 13:44:27 UTC