- From: Andrea Perego <andrea.perego@uninsubria.it>
- Date: Wed, 28 Mar 2007 11:39:44 +0200
- To: Public POWDER <public-powderwg@w3.org>
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 Wednesday, 28 March 2007 09:36:28 UTC