- From: Phil Archer <parcher@icra.org>
- Date: Wed, 28 Mar 2007 09:29:23 +0100
- To: public-powderwg@w3.org
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 08:29:43 UTC