Re: meta-DRs abd grouping by resource property

Stasinos Konstantopoulos wrote:
> On Mon Apr  7 20:33:51 2008 Phil Archer said:
> 
>> I agree that we have to keep resource set definitions out of the picture 
>> but we _do_ have a specific use case where the kind of thing you suggest 
>> does occur. When we use a DR to certify another DR, it's useful to be 
>> able to include a hash of the DR we're certifying. See [6]
>>
>> <descriptorset>
>>   <sha1sum>j6lwx3rvEPO0vKtMup4NbeVu8nk=</sha1sum>
>>   <certified>true</certified>
>>   <displaytext>authority.example.org certifies that claims made
>>      by example.com are true. Valid throughout 2008.</displaytext>
>>   <displayicon>http://authority.example.org/icon.png</displayicon>
>> </descriptorset>
>>
>> I just wrote this into the doc, we haven't discussed it but I'd very 
>> much like to. It says that the description of the IRI set (which in the 
>> full example is a single URI) has a SHA-1 hash value. There is no formal 
>> semantics at work here, just a "we say that if you take a SHA-1 hash of 
>> the resource, it's this value."
> 
> This looks easy enough, especially if restricted to complete POWDER docs
> and not fragments (individual DRs).

Yes - the current doc may need to make that clearer but the text says 
that it is only useful where the scope is a single URI - which I know is 
a bit woolly.


  A POWDER doc is a resource just like
> any other, so, as things stand, one can describe it with <sha1sum/> just
> like any other vocabulary item. POWDER tools will have to know what to
> do with this.

Yes.

> 
> Generic RDF tools will have to accept the assertion that a certain
> resource has a certain <sha1sum/> property. If some process provides an
> alternative means for assigning this property (e.g. a tool for resolving
> the resource's IRI and calculating the checksum) then the potential
> inconsistency will be caught.

OK, let's put that in the specification for the Jena extension.

> 
> There is another thing one might want to express that is trickier. I
> am going to use <sha1sum/> as an example, but could be any property.
> I am assuming <sha1sum/> is only sensible for resolvable URL and not any
> URI, so it should be at the wdrurl layer:
> 
> <dr>
>   <iriset>
>     <wdrurl:includeURL>http://example.com/powder.xml</wdrurl:includeURL>
>     <wdrurl:includeproperty ref="sha:sha1sum">
>       j6lwx3rvEPO0vKtMup4NbeVu8nk=
>     </wdrurl:includeproperty>
>   </iriset>
> 
>   <descriptorset>
>     <certified>true</certified>
>     <displaytext>authority.example.org certifies that claims made
>       by example.com are true. Valid throughout 2008.
>     </displaytext>
>     <displayicon>http://authority.example.org/icon.png</displayicon>
>   </descriptorset>
> </dr>
> 
> The descriptorset applies to all documents that are at
> http://example.com/powder.xml AND
> have property sha:sha1sum with value j6lwx3rvEPO0vKtMup4NbeVu8nk=

[..]

This, as you know, brings back the idea of grouping resources by their 
properties - something we discussed and thought about for /months/. As I 
recall the main problems were:

1. The ease of creating logical nonsense - all things that are blue are red

2. The enormous difficulty of defining a generic look-up mechanism. How 
do I know that the thing is blue?

3. It breaks POWDER's power of discovery. If I have to fetch something 
to find out whether I wanted it in the first place, that, to use a W3C 
phrase, is not optimal. It makes it impossible to determine whether a 
candidate IRI is or is not a member of the IRI set based on the 
information already available. (Actually, this argument suggests we 
should perhaps drop IP addresses as an IRI constraint but not strongly IMHO)

4. The final nail in the coffin was Jeremy's e-mail [1] in which he sets 
out why our sets are sets of IRIs, not sets of resources (because a 
single resource can have any number of IRIs pointing to it).

IRI sets are the most heavily constrained parts of POWDER - and for good 
reason. The schema will limit the elements that can be children of 
<iriset /> to terms within the POWDER namespace and no more - this to 
keep a reasonably tight rein of the semantics.

Having said that, it does 'feel more logical' for the checksum to go in 
the IRI set than in the descriptors.

If we defined an IRI constraint of sha1sum (and maybe md5 and sha2) 
might that work? I would be very happy to be proved wrong but I don't 
think it it would - because all the problems above would still apply. 
Putting the checksum in the descriptors means that, as set out in [2], 
the DR publisher is describing the certified resource very precisely. A 
POWDER-enabled system that aggregated resources described by POWDER 
documents certified by a given authority would be able to make use of 
that data perfectly well.

Phil.


[1] http://lists.w3.org/Archives/Public/public-powderwg/2007Dec/0045.html
[2] http://www.w3.org/TR/2008/WD-powder-dr-20080317/#interpretCert

Received on Friday, 18 April 2008 08:37:22 UTC