W3C home > Mailing lists > Public > public-powderwg@w3.org > May 2008

Re: Proposal to drop support for pointing to a specific DR

From: Phil Archer <parcher@icra.org>
Date: Thu, 08 May 2008 16:18:00 +0100
Message-ID: <482319A8.9080604@icra.org>
To: Public POWDER <public-powderwg@w3.org>

No, that's no correct. You can have a single document that has all the 
DRs you need, or spread them over several, all it means is that you 
can't do things like this

<ol>
   <dr xml:id="DR_1!>
     <iriset>...</iriset>
     <descriptorset>...<descriptorset>
   </dr>

   <dr ref="http:doc2.xml#DR_2" />
</ol>

You'd have to have members of an ordered list in the same document.

Basically it means that each POWDER document stands on its own. If you 
want to, you can point from one to another, but at document level, not 
individual DR level. And you can't have a DR in one doc override one in 
another document.

Linking directly to a description (in any document) is unaffected.

P

Scheppe, Kai-Dietrich wrote:
> Meant to go to the group...
> 
> Hi Phil,
> 
> If I understand this correctly it also means that we will NOT be able to
> have one or a few documents that contain all the DRs we need.
> 
> Is that correct?
> 
> -- Kai  
> 
>> -----Original Message-----
>> From: public-powderwg-request@w3.org 
>> [mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
>> Sent: Thursday, May 08, 2008 11:27 AM
>> To: Public POWDER
>> Subject: Re: Proposal to drop support for pointing to a specific DR
>>
>>
>> The further implications of this - dropping support for 
>> linking directly to a specific DR rather and only talking in 
>> terms of linking to a POWDER document - is that the very 
>> confusing and potentially troublesome business of having 
>> ordered lists of DRs across multiple documents can be got rid 
>> of. Section 2.4.1 [1] suggests using dc:isPartOf and well, it 
>> just looks ugly. I don't think we lose anything, and gain a 
>> lot of clarity, if we say that ordered lists of DRs must be 
>> in a single document.
>>
>> All of which means that we can drop the whole of section 2.4 
>> and just have a note in the linkage section that allows one 
>> POWDER doc to point to another so that once you've found one 
>> POWDER doc, you can find other related ones - something I 
>> think Kai has mentioned a few times.
>>
>> Unless someone screams, I'll do this in the version I'm 
>> editing now (it can always be put back).
>>
>> Phil.
>>
>>
>> [1] http://www.w3.org/TR/2008/WD-powder-dr-20080317/#partOf
>>
>> Phil Archer wrote:
>>> We have a slight problem, but only a slight one.
>>>
>>> In the current published version of the DR doc there's a section on 
>>> "Multiple DRs With Different Attribution" [1]. This 
>> suggests that you 
>>> can do this:
>>>
>>> <dr xml:id="red">
>>>   <iriset>
>>>     <includehosts>example.com</includehosts>
>>>   </iriset>
>>>
>>>   <descriptorset>
>>>     <palette:color>red</palette:color>
>>>   </descriptorset>
>>> </dr>
>>>
>>> <dr ref="http://example.com/powder2.xml#square" />
>>>
>>> i.e. link from a POWDER doc to a specific DR in another doc.
>>>
>>> Well, you can in POWDER. The semantics here being that after you've 
>>> finished parsing the first DR, you might want to go and 
>> take a look at 
>>> http://example.com/powder2.xml#square. Fine... but it doesn't 
>>> translate exactly into POWDER-S. At least, not as we're now 
>> writing it 
>>> following the discussion over how to express the sub class 
>>> relationship [2]. The simpler way to assert the sub class, 
>> and in my 
>>> view the more natural way, is to do this:
>>>
>>> <owl:Class rdf:about="#resourceset_1">
>>>   <rdfs:subClassOf rdf:ID="description_1"/> </owl:Class>
>>>
>>> This has particular benefits when it comes to expressing 
>> ordered lists 
>>> in POWDER-S where it becomes a very elegant and simple way of 
>>> excluding IRI sets that should be excluded 'cos they're 
>> higher up the 
>>> list (see the Stasinos paper on this).
>>>
>>> But... notice that the descriptor set and IRI set have their 
>>> identifiers and the bit of RDF/OWL here just adds to the 
>> information 
>>> about
>>> resourceset_1 - it has no identity of its own. Therefore, there is 
>>> nowhere to use the 'square' identifier that we had in the original 
>>> POWDER XML.
>>>
>>> Does this matter?
>>>
>>> What exactly should a processor do with the information 
>> that 'there's 
>>> another DR at http://example.com/powder2.xml#square ? Shouldn't it 
>>> first decide whether to trust it or not? If you go straight 
>> to the DR 
>>> you might skip the attribution information - which goes against the 
>>> ethos somewhat (and means a different processing model depending 
>>> whether you arrive at the DR with or without a fragment 
>> identifier). I 
>>> think it could be argued... OK, I will argue... that the 
>> better thing 
>>> to do is to link to the external document as a whole. One 
>> might think of it like this:
>>> <attribution>
>>>   <maker ref="http://www.example.org/foaf.rdf#me" /> </attribution>
>>>
>>> <dr xml:id="red">
>>>   <iriset>
>>>     <includehosts>example.com</includehosts>
>>>   </iriset>
>>>   <descriptorset>
>>>     <palette:color>red</palette:color>
>>>   </descriptorset>
>>> </dr>
>>>
>>> <seealso ref="http://example.com/powder2.xml" />
>>>
>>> In POWDER-S that last element would become:
>>>
>>> <rdf:Description rdf:about="">
>>>   <rdfs:seeAlso rdf:resource="http://example.com/powder2.xml
>>> </rdf:Description>
>>>
>>> Which means, in POWDER-S, you may as well put it in what we 
>> think of 
>>> as the attribution block since the subject of the triple is the 
>>> document itself, as is the case for the foaf stuff etc.
>>>
>>> I hope I'm making this clear although I fear I may not be :-(.
>>>
>>> Basically, I'm arguing that we should just use an element called 
>>> <seealso /> to link from one POWDER doc to another and not 
>> worry about 
>>> linking to a specific DR.
>>>
>>> Phil.
>>>
>>>
>>> [2] 
>>>
>> http://lists.w3.org/Archives/Public/public-powderwg/2008Apr/0034.html
>>> [1] http://www.w3.org/TR/2008/WD-powder-dr-20080317/#multiDRatt
>>>
Received on Thursday, 8 May 2008 15:18:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:12 GMT