Re: Blank nodes in descriptor sets - a proposal to deal with this using Occam's Razor

Phil Archer wrote:
> [..]
>> The correct statement is something like: "there is at least one 
>> resource somewhere that is the object of a triple whose subject is the 
>> descriptorset, and the property is ex:material, and this resource has 
>> the type ex:Wood, has the property ex:finish, etc." Ie, ex:Wood is not 
>> the value of ex:material!
> OK, thank you.
>>>            Since, in a POWDER environment, this may not be true the 
>>> logic doesn't hold.
>> Why?
> Because there may not be that one resource. There are a couple of ways 
> to define a descriptor set in POWDER that actually describes nothing. 
> Although this is not normally the case, it is possible. Also, it is 
> normal that new resources are added to the Web that are described by 
> descriptor sets that have already been defined.

Ah! I understand. And yes, that is indeed a conceptual problem. Ie, it 
is not blank nodes in general but for its usage in POWDER that it might 
lead to problems. Thanks.

>>> In consequence, Stasinos has suggested to the group that we need to 
>>> have something like this
>>> 1  <descriptorset>
>>> 2    <ex:material>
>>> 3      <ex:Wood ref="">
>>> 4        <ex:finish rdf:resource=""/>
>>> 5        <ex:madeof>cedar</ex:madeof>
>>> 6      </ex:Wood>
>>> 7     </ex:material>
>>> 8  </descriptorset>
>>> My problem is the 'ref' attribute. A descriptor set is meant to to 
>>> carry RDF/XML directly so adding in non-RDF attributes strikes me as 
>>> something to avoid if we can. rdf:ID or rdf:about is what we really 
>>> need isn't it?
>> I am not sure what the Stasinos' intention is with @ref. Doesn't that 
>> depend on the transformation into POWDER-S?
> I left out his transformation which gives:
> 1   <owl:Class rdf:ID="polishedcedar">
> 2     <owl:intersectionOf rdf:parseType="Collection">
> 3       <owl:Restriction>
> 4         <owl:onProperty rdf:resource=""/>
> 5         <owl:hasValue rdf:resource=""/>
> 6       </owl:Restriction>
> 7       <owl:Restriction>
> 8         <owl:onProperty rdf:resource="">
> 9         <owl:hasValue>cedar</owl:hasValue>
> 10      </owl:Restriction>
> 11    </owl:intersectionOf>
> 12  </owl:Class>
> 13  <owl:Class rdf:nodeID="descriptorset_1">
> 14    <owl:intersectionOf rdf:parseType="Collection">
> 15      <owl:Restriction>
> 16        <owl:onProperty 
> rdf:resource=""/>
> 17        <owl:hasValue rdf:resource="polishedcedar"/>
> 18      </owl:Restriction>
> 19    </owl:intersectionOf>
> 20  </owl:Class>
> Although the text is normative and the XSLT is just an implementation - 
> it would be helpful not to stretch the XSLT too far (and I think this 
> probably does)

I am a lousy XSLT programmer, so I cannot judge that. I simply believe 
it:-) There is no real problem I could see with this transformation, 
though from the specification point of view. The question is how many 
real use cases you have (the ones I had does _not_ fall under those if 
my understanding of what you say is correct) and whether they are worth 
the trouble. If no real use case then...

> It's about efficiency. Every time you ask a POWDER Processor to describe 
> <u> where <u> is some URI in the scope of the DR of which this is the 
> descriptor set, it's going to generate all those triples. It's not 
> wrong, just unnecessarily repetitive and therefore can be seen as bad 
> practice, especially since one of our motivations is the efficient 
> creation and use of metadata.

O.k. I believe you (you have clearly run this through your mind _much_ 
more often than I did:-)

>>>                                                         So people 
>>> should probably be warned off defining a description within a POWDER 
>>> doc - but it is valid RDF and it does match the 'no blank nodes' rule.
>>> Using RDF:ID gives a rather different (and almost certainly wrong) 
>>> result since, if I've got this right (and I'm far from sure) polished 
>>> cedar is now tied to <u> thus:
>>> <u> ex:material <u#polishedcedar>
>> Yes, that is correct.
> I got something right ! :-)


> [snip]
>> Well... to use the example above if I leave out the rdf:type, that 
>> means that I rely on some external mechanism to infer the typing. That 
>> is of course possible (eg, the domain of attributionURL is Work, ie, 
>> strictly speaking the typing is not necessary).
> For rdf:type and rdfs:seeAlso, comment and label we're defining new 
> elements called, guess what: typeof, seealso, label and comment - that 
> are transformed into rdf:type and the rdfs properties. 

Such simple guys:-) In the RDFa group we haggled for weeks whether the 
right name for the attribute we use is... @typeof. All those geeks over 

Seriously: that takes away my arguments indeed.

>                                                         As a failsafe, 
> however, the transformation will _also_ allow you to write those 
> well-known properties in directly (as you did) and they'll still be 
> transformed properly. 

Even better!

>                        Other rdfs properties won't be trapped but, well, 
> there are many ways to write gibberish in POWDER.


> [..]
>> But how does this address my other issue, namely that the 
>> transformation will generate a restriction for, say, @rdf:seeAlso 
>> (which I _can_ use according to your rules) and that will then kick 
>> out the generated OWL from OWL-DL right away? What will happen to those?
> See above.

Yep, this is fine!

Well, I did not give any explicit advise:-) but I hope I was helpful 


> Thanks as always for your time and help.
> Phil.


Ivan Herman, W3C Semantic Web Activity Lead
PGP Key:

Received on Wednesday, 16 July 2008 13:36:58 UTC