- From: Phil Archer <parcher@icra.org>
- Date: Tue, 22 Jan 2008 09:34:52 +0000
- To: public-powderwg@w3.org
- CC: Jeremy Carroll <jjc@hpl.hp.com>
There are some errata in this e-mail. Example 1 - the ex:shape property should have the value "square" Example 4, DR_2 - the <includePathStartsWith> property should be deleted, i.e. the URI sets of both DRs in Example 4 should be identical (but the descriptions are different). The sample files and graphs have been corrected. Phil Archer wrote: > > As promised on Friday afternoon, here are some musings on a possible new > structure for Operational POWDER (POWDER-O), taking into account the > recent discussion. > > > Example 1 > ========= > RDF/XML: http://www.fosi.org/projects/powder/dr-o1.rdf > Graph: http://www.fosi.org/projects/powder/servlet_63142.png > > Let's begin with a simple case, that all resources dereferenced from a > URI with a host component ending with example.org are red and square (I > got these line numbers from the RDF validator but I've knocked off the > namespace declarations). > > 11: <rdf:Description rdf:about=""> > 12: <foaf:maker > rdf:resource="http://authority.example.org/foaf.rdf#me" /> > 13: <dcterms:issued>2007-12-14</dcterms:issued> > 14: <wdr:validFrom>2008-01-01</wdr:validFrom> > 15: <wdr:validUntil>2008-12-31</wdr:validUntil> > 16: </rdf:Description> > 17: > 18: <wdr:DR rdf:ID="DR_1"> > 19: <wdr:hasScope rdf:parseType="Resource"> > 20: <wdr:includeHosts>example.org</wdr:includeHosts> > 21: <wdr:hasDescriptors rdf:parseType="Resource"> > 22: <ex:colour>red</ex:colour> > 23: <ex:shape>red</ex:shape> > 24: </wdr:hasDescriptors> > 25: </wdr:hasScope> > 26: </wdr:DR> > > The document was made by "...#me" on 14th December 2007 and as valid for > 2008. If you trust "...#me" and today's date is in 2008, then the DR in > the document can be transformed into its semantic encoding (DR-S) and > the RDF merged into your triple store for processing. > > The single DR in the document has: > 1. a URI set defined solely in terms of its host (example.org) and there > are two descriptors from the ex namespace. > > Now let's make it a little more complicated and have one DR but two URI > sets. > > Example 2 > ========= > RDF/XML: http://www.fosi.org/projects/powder/dr-o2.rdf > Graph: http://www.fosi.org/projects/powder/servlet_63180.png > > 11: <rdf:Description rdf:about=""> > 12: <foaf:maker > rdf:resource="http://authority.example.org/foaf.rdf#me" /> > 13: <dcterms:issued>2007-12-14</dcterms:issued> > 14: <wdr:validFrom>2008-01-01</wdr:validFrom> > 15: <wdr:validUntil>2008-12-31</wdr:validUntil> > 16: </rdf:Description> > 17: > 18: <wdr:DR rdf:ID="DR_1"> > 19: > 20: <wdr:hasScope rdf:parseType="Collection"> > 21: > 22: <wdr:URIset rdf:ID="URIset_1"> > 23: <wdr:includeHosts>example.org</wdr:includeHosts> > 24: <wdr:includePathStartsWith>/foo</wdr:includePathStartsWith> > 25: <wdr:hasDescriptors rdf:parseType="Resource"> > 26: <ex:colour>red</ex:colour> > 27: </wdr:hasDescriptors> > 28: </wdr:URIset> > 29: > 30: <wdr:URIset rdf:about="#URIset_2" /> > 31: > 32: </wdr:hasScope> > 33: > 34: </wdr:DR> > 35: > 36: <wdr:URIset rdf:ID="URIset_2"> > 37: <wdr:includeHosts>example.org</wdr:includeHosts> > 38: <wdr:hasDescriptors rdf:parseType="Resource"> > 39: <ex:colour>blue</ex:colour> > 40: </wdr:hasDescriptors> > 41: </wdr:URIset> > > The attribution and validity information (lines 11 - 16) remain > unchanged. Now though our DR contains two URIsets and two attendant > descriptions. All resources identified by URIs with that have host > components ending with example.org are blue except those where the path > starts with /foo which are red. > > If the trust and validity information is to your satisfaction, then you > can transform this operational data into two DR-S instances and merge > the RDF. N.B. The transformation must contain data from both URI sets thus: > > <wdr:URISet rdf:ID="URISet_1"> > <owl:intersectionOf rdf:parseType="Collection"> > <owl:Restriction> > <owl:onProperty rdf:resource="&wdr;includeHosts" /> > <owl:hasValue>example.org</owl:hasValue> > </owl:Restriction> > <owl:Restriction> > *<owl:onProperty rdf:resource="&wdr;includePathStartsWith" />* > <owl:hasValue>/foo</owl:hasValue> > </owl:Restriction> > </owl:intersectionOf> > </wdr:URISet> > > And > > <wdr:URISet rdf:ID="URISet_2"> > <owl:intersectionOf rdf:parseType="Collection"> > <owl:Restriction> > <owl:onProperty rdf:resource="&wdr;includeHosts" /> > <owl:hasValue>example.org</owl:hasValue> > </owl:Restriction> > <owl:Restriction> > *<owl:onProperty rdf:resource="&wdr;excludePathStartsWith" />* > <owl:hasValue>/foo</owl:hasValue> > </owl:Restriction> > </owl:intersectionOf> > </wdr:URISet> > > The exclude path starts with property in URISet 2 is generated by: > > 1. Noting the defining features of URISet 1 (example.org and /foo) > 2. Noting the defining features of URISet 2 (example.org) > 3. Taking the inverse of those present in 1 but absent in 2. > (example.org and NOT /foo) > > This is going to get complicated when there are n URISets in the > sequence but hey, let's be optimistic... > > We can add further DRs into the document iff the validity information is > the same. I won't copy it out here but such an example is available: > > Example 3 > ========= > RDF/XML: http://www.fosi.org/projects/powder/dr-o3.rdf > Graph: http://www.fosi.org/projects/powder/servlet_63202.png > > This says that everything on example.org is blue except things with a > URI path starting with /foo which are red. Separately, everything on > example.org is circular except things with a URI path starting with /bar > which is square. All assertions are subject to the same validity/trust > conditions. And you process the Collections within each of the DRs to > get these results or, if you want to merge the RDF into your triple > store, you perform the transformation to get the full OWL-based version. > > Two people providing different descriptions with different validity > dates will need to publish separate RDF/XML instances. > > N.B. > > I have written these examples with the exceptional case written within > the DR and the 'default' description (there's no other word for it) as a > separate block. There is no difference in structure but it does reflect > what I expect to be the workflow reality - we're describing everything > in a given URI set as being like _this_ *except* things that have > _these_ things in their URIs which are like _this_ instead. Less > abstract: there is no sex, drugs or rock and roll on fosi.org _except_ > where the URI path component begins with /associates where there might > be. Operationally, you write the general case first and then worry about > the exceptions in a separate thought process. > > All of the RDF/XML instances given so far have a single URI so that a > Web site can include an identical link element pointing to such a file > irrespective of whether the resource is red, blue, square or circular - > the POWDER client will sort it out. > > But, where the Web site has no (discernible or usable) URI structure, > this isn't good enough. We need to include a new conditional statement, > linkFrom, that says that if you trust "...#me" and today's date is > within range *and* the resource includes a link to a specific DR, _then_ > it is valid. > > The next example shows this. > > Example 4 > ========= > RDF/XML: http://www.fosi.org/projects/powder/dr-o4.rdf > Graph: http://www.fosi.org/projects/powder/servlet_63230.png > > 11: <rdf:Description rdf:about=""> > 12: <foaf:maker > rdf:resource="http://authority.example.org/foaf.rdf#me" /> > 13: <dcterms:issued>2007-12-14</dcterms:issued> > 14: <wdr:validFrom>2008-01-01</wdr:validFrom> > 15: <wdr:validUntil>2008-12-31</wdr:validUntil> > 16: <wdr:linkFrom>true</wdr:linkFrom> > 17: </rdf:Description> > 18: > 19: <wdr:DR rdf:ID="DR_1"> > 20: <wdr:hasScope rdf:parseType="Resource"> > 21: <wdr:includeHosts>example.org</wdr:includeHosts> > 22: <wdr:hasDescriptors rdf:parseType="Resource"> > 23: <ex:texture>smooth</ex:texture> > 24: </wdr:hasDescriptors> > 25: </wdr:hasScope> > 26: </wdr:DR> > 27: > 28: > 29: <wdr:DR rdf:ID="DR_2"> > 30: <wdr:hasScope rdf:parseType="Resource"> > 31: <wdr:includeHosts>example.org</wdr:includeHosts> > 32: <wdr:includePathStartsWith>/sawn</wdr:includePathStartsWith> > 33: <wdr:hasDescriptors rdf:parseType="Resource"> > 34: <ex:texture>rough</ex:texture> > 35: </wdr:hasDescriptors> > 36: </wdr:hasScope> > 37: </wdr:DR> > > Notice line 16 which introduces the linkFrom element. > > Then the URI sets for each DR are identical - everything on example.org > - you need to refer to the linkFrom element to decide which is > applicable (actually, you'd probably define the URI set once in a > separate block and refer to it from both DRs). I know this is a pain - > deliberately publishing two sets of triples that say different things > about the same subjects - but, as they say in Vladivostok, c'ést la Guerre. > > What about storing lots of DRs in a single RDF/XML instance? Well, it's > clear that we can't. If you're a content provider and you need to have > several DRs covering different domains of interest then you simply > create multiple RDF/XML files and link as you need to. If you're a > labelling authority you store your DRs in a database with a front end > like, oh I dunno, http://repository.icra.org/label?id=1 :-) which calls, > I mean, would call a script that would return a single RDF/XML instance. > > This might mean we re-visit the issue of whether we want to put a hint > in the link element as to what vocabularies are used in a given DR. > > If this is along the right lines then it seems to me we need to revisit > the question of whether a DR-O is written in RDF/XML, just XML or > something in between. All the examples above are valid RDF/XML but we > have not got rid of the problem of generic RDF tools sucking in the > triples and trying to make sense of them out of context. Personally I'm > tending towards DR-Os being written in XML with only DR-Ss in RDF. It > seems that GRDDL cannot transform RDF/XML and, I think I'm right in > saying, that XSLT will have difficulty too. > > I'll do some more playing around with that now... > > Phil. > > > > Phil Archer wrote: >> >> Good, this feels as if we're making progress (or rather, you're making >> progress in a promising direction :-)). >> >> I'll do some more playing around on Monday morning and see if I come >> up against anything we're missing. >> >> Have a good weekend and thank you. >> >> Phil. >> >> Jeremy Carroll wrote: >>> >>> Phil Archer wrote: >>>> >>>> >>>> Jeremy Carroll wrote: >>>> [snip] >>>>> >>>>> If we choose to make the GRDDL transform make the DR-S include the >>>>> subClassOf relationship as above, then we have the issue that in a >>>>> package (or any collection of DRs) some of the DRs may be valid and >>>>> some may be invalid, and all the subClassOf relationships are in >>>>> the same file, and it is unclear how to distinguish the ones we >>>>> want to claim (the valid ones), from the ones we don't (the invalid >>>>> ones). >>>> >>>> I take this point. It may be that we can do something about it >>>> though. We have so far taken the view that a DR should be >>>> self-contained and that a package is therefore a group of >>>> self-contained units. Doing this means that the validity information >>>> (and attribution) is NOT inherited by DRs in the package. However... >>>> we then had to introduce the idea of using dcterms:isPartOf to force >>>> the processing of these "discrete DRs" in a particular order [1]. In >>>> such a scenario, yes, each DR would have its own validity and >>>> attribution. >>>> >>>> But it doesn't have to be this way... >>>> >>>> It would be possible I think to work with the package carrying the >>>> validity information that was then inherited by the DRs within that >>>> package - which I think from what you say would make life easier? >>>> >>>> >>> >>> >>> Yes - I was thinking along these lines. >>> >>> I was discussing this with Stuart - a possible view is then: >>> >>> The unit of a POWDER description is a document, which may contain a >>> single wdr:DR or a single wdr:Package. >>> >>> Either way the document has information pertinent to the relevance of >>> the document: >>> e.g. validity and who vouches for it. >>> >>> Operationally the process of trust is as follows: >>> >>> for each possible document that you might be considering, you read >>> that document, then understanding what that document says about >>> itself, if you are satisfied that you want to act on that document >>> (e.g. it is valid, and is vouched for by an appropriate authority), >>> then you load it into your knowledge base (formally corresponding to >>> an RDF merge using the POWDER-S GRDDL result) >>> >>> The resulting RDF graph consists of only valid POWDER DRs, which have >>> been vouched for by appropriate authorities. >>> >>> From the formal side the motivations for doing this way are: >>> - it is known that temporal logics (i.e. dealing with time in a >>> logical way) is a hard problem >>> - it is known that dealing with trust in logic is a hard problem >>> - it is clear that POWDER deals with both time and trust, but in >>> simple ways >>> - hence it feels inappropriate to do the time and trust parts in the >>> formal logical layer, but to deal with them in a pragmatic layer >>> prior to, but informed by, the logical treatment >>> >>> It is a limitation of the current RDF technology that it is hard to >>> talk about part of an RDF graph, and its validity, or who vouches for >>> that part - hence the desire to talk about documents containing >>> RDF/XML that expresses those parts of the graph. >>> I think it is possible to design documents of the 'right' size so that: >>> >>> - validity and vouching are pertinent on a document by document level >>> (and not on a finer grain) >>> - documents are large enough that the small scale powder user need >>> only write one document for their site, or maybe two. >>> >>> - that the expectations on large publishers who may need to make >>> declarations that fit into complex workflows are intelligible and not >>> too burdensome. >>> >>> Jeremy >>> >
Received on Tuesday, 22 January 2008 09:35:18 UTC