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

Ivan Herman wrote:
> 
> 
> Phil Archer wrote:
>> Sorry this is long but it's kind of an argument made in public leading 
>> to a proposed resolution.
>>
>> Ivan - I'm copying you in as this has been triggered by your comment 
>> and expertise - and it has a question for you which, I'm sorry, is 
>> quite a long way down.
>>
>> Dan - I think this addresses the issue you've had with this from the 
>> start.
>>
>> Picking up from Ivan's comments [1], clearly we need to do a bit of 
>> work on this 'no blank nodes' business. My own lack of understanding 
>> isn't much of a help here but given that we've been told explicitly 
>> that blank nodes are things we really can't have in a POWDER 
>> descriptor set, let's see what we have to do.
>>
> 
> I do not know the arguments in favour of this statements and, in 
> general, I am reluctant to buy into the 'blank nodes are evil, avoid 
> them at all costs' argument. Yes, they can be a pain in the neck 
> sometimes but there might be cases where they are quite useful... But if 
> you guys have made this decision, I certainly do not want to reopen this 
> can of worm!:-) Ie, I accept the premise.

Dan and Jeremy we quite clear about this when I met up with them before 
Christmas and Dan has been saying similar things - i.e. it matters what 
kind of thing you want to say with POWDER - for a long time 
(http://lists.w3.org/Archives/Public/public-xg-wcl/2006Jun/0000.html)

My problem is that, despite Dan's patience, I still don't fully 
understand this - I take it on trust.
[..]
> 
> 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.

> 
>>
>> 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="http://example.org/vocab#polishedcedar">
>> 4        <ex:finish rdf:resource="http://example.org/vocab#shiny"/>
>> 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="http://example.org/vocab#finish"/>
5         <owl:hasValue rdf:resource="http://example.org/vocab#polished"/>
6       </owl:Restriction>
7       <owl:Restriction>
8         <owl:onProperty rdf:resource="http://example.org/vocab#madeof/">
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="http://example.org/vocab#material"/>
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)


  You mean that it compiles to
> what is below?
> 
>> If the intention is to create or use a node within the 'ex' namespace 
>> then it needs to be rdf:about thus:
>>
>> 1  <descriptorset>
>> 2    <ex:material>
>> 3      <ex:Wood rdf:about="http://example.org/vocab#polishedcedar">
>> 4        <ex:finish rdf:resource="http://example.org/vocab#shiny"/>
>> 5        <ex:madeof>cedar</ex:madeof>
>> 6      </ex:Wood>
>> 7     </ex:material>
>> 8  </descriptorset>
>>
>> For our candidate resource <u>, writing this out long hand gives us 
>> these triples:
>>
>> <u> ex:material    <http://example.org/vocab#polishedcedar>
>>
>> <http://example.org/vocab#polishedcedar> rdf:type 
>> <http://example.org/vocab#Wood>
>>
>> <http://example.org/vocab#polishedcedar> ex:finish 
>> <http://example.org/vocab#shiny>
>>
>> <http://example.org/vocab#polishedcedar> ex:madeof "cedar"
>>
> 
> Yes, this is correct...
> 
>> Whilst this is OK, it's hardly efficient. It would be much more 
>> efficient to define polished cedar in the ex vocabulary (or some other 
>> vocabulary, it doesn't matter), and use 
>> rdf:resource="http://example.org/vocab#polishedcedar". 
> 
> Phil, I am sorry, I am lost here. You are not supposed to use 
> @rdf:resource simply because
> 
> <ex:Wood rdf:about="http://example.org/vocab#polishedcedar">
>   <ex:finish rdf:resource="http://example.org/vocab#shiny"/>
>   <ex:madeof>cedar</ex:madeof>
> </ex:Wood>
> 
> is syntactic sugar for
> 
> <rdf:Description rdf:about="http://example.org/vocab#polishedcedar">
>   <rdf:type rdf:resource="http://example.org/vocab#Wood"/>
>   <ex:finish rdf:resource="http://example.org/vocab#shiny"/>
>   <ex:madeof>cedar</ex:madeof>
> </rdf:Description>
> 
> I do not really understand what the difference/problem is.

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.


> 
>>                                                         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. 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. 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.

Thanks as always for your time and help.

Phil.

Received on Wednesday, 16 July 2008 13:21:16 UTC