Re: PROPOSAL to allow multiple descriptor sets in DRs

In short, we agree and the restriction point out is fine by me. Longer...

POWDER descriptor set elements can have a src attribute that points to 
another descriptor set that can be in any POWDER doc. Therefore they may 
well be subject to an abouthosts restriction (which is encoded in the 
descriptor set class). If someone is careless enough to create a DR that 
includes multiple descriptors, any one of which is subject to an about 
hosts restriction that doesn't include the relevant IRI set, then I'd 
say it's a good thing that the whole DR becomes logically meaningless 
(since it must be an error).

Phil.

Stasinos Konstantopoulos wrote:
  On Wed Jun 11 10:14:07 2008 Phil Archer said:
> 
>> I've been looking at the implications of allowing more than one  
>> descriptor set (and tagset) within a DR and can't find a reason to limit  
>> their cardinality to one - which is probably good.
>>
>> The use case for this would be where one organisation is creating DRs  
>> [...]
>>
>> To process either DR you'd fetch the two descriptor sets identified in  
>> the src attributes and apply them all to whatever your candidate  
>> resource was. So allowing multiple descriptor sets allows you to mix and  
>> match them within a DR - something I recall talking to Dave/Segala about  
>> in the past as being something that would be useful.
> 
> Will all descriptorsets be defined in the same file, and as a
> consequence share a single abouthosts?
> 
> If yes, then:
> 
>> It works in POWDER-S too.
>>
>> Each of those descriptor sets would create an OWL class with an nodeID  
>> of descriptorset_x and the sub class relationship would be
>>
>> <owl:Class rdf:about="#iriset_1">
>>   <rdfs:subClassOf rdf:resource="#descriptorset_1"/>
>>   <rdfs:subClassOf rdf:resource="#descriptorset_2"/>
>> </owl:Class>
>>
>> Look OK to everyone?
> 
> looks OK.
> 
> If we allow any rdf:resource and not only local names, then if any
> single one of the descriptorsets is associated with an abouthosts that
> does not cover the resource, then the whole description becomes invalid.
> It is not (at least as things stand) possible "filter out" the offending
> descriptorset and apply the remaining ones.
> 
> s
>

Received on Wednesday, 11 June 2008 12:58:37 UTC