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

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.

> This is wrong:
> 
> 1  <descriptorset>
> 2    <ex:material>
> 3      <ex:Wood>
> 4        <ex:finish rdf:resource="http://example.org/vocab#shiny"/>
> 5        <ex:madeof>cedar</ex:madeof>
> 6      </ex:Wood>
> 7     </ex:material>
> 8  </descriptorset>
> 
> because ex:Wood, although is is of a defined type(ex:Wood), it is still 
> a blank node. If I understand Dan and JJC correctly, I believe writing 
> this means that the universe is arranged in such a way that there is at 
> least one resource that has the property ex:material with the value 
> ex:Wood. 

Hm. No, this is not correct, although your statements below seem to work 
the right way. Ie, maybe you did not write what you thought...

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!

>            Since, in a POWDER environment, this may not be true the logic 
> doesn't hold.

Why?

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

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

> And u#polishedcedar becomes the subject of the other triples (and just 
> to add spice, u might include a fragment of its own then we're
> really messed up). 

:-) or rather: :-(

>                     I guess this _could_ be the intention but my hunch is 
> that it will normally be an error... and this probably means we should 
> see if we can ban the use of rdf:ID within a descriptor set.
> 
> Hmmm...
> 
> It seems to me that doing anything other than one of these two:
> 
> A) <ex:property1>literal value</ex:property>
> B) <ex property2 rdf:resource="...#thing" />
> 
> is likely to be one of:
> 
> 1. Bad semantics
> 2. Bad practice
> 3. Plain wrong
> 
> And even there you need to be careful that the URI in (B) is an instance 
> and not a class!
> 
> Which I guess is why Stasinos suggested adding the ref attribute ;-)
> 
> So right now I'm tending towards suggesting that we only allow literal 
> values or rdf:resource and no child elements of child elements of 
> descriptorset.
> 
> Let's cycle back to a discussion we had at the f2f on Monday.
> 
> If we allow people to write their foaf:Agent or dcterms:Agent class 
> directly into a POWDER doc that means that to process POWDER you MUST 
> understand RDF. We decided that this was OK because you MUST understand 
> RDF to process a descriptorset.
> 
> If we were to restrict a descriptorset to only allowing literals or 
> rdf:resources then you could probably go a long way in processing POWDER 
> without understanding RDF at all if you didn't want to. Let's take 
> Ivan's copyright example. Cutting out some of the detail to fit in an 
> e-mail format he has this:
> 
> <descriptorset>
>   <displaytext>Logos must...</displaytext>
>   <rdf:type rdf:resource="http://creativecommons.org/ns#Work"/>
>   <rdfs:seeAlso rdf:resource="http://www.w3.org..."/>
>   <xhtml:license rdf:resource='http://www.w3.org...'/>
>   <cc:morePermissions rdf:resource='...'/>
>   <cc:attributionURL rdf:reource='http://www.w3.org/2001/sw/'/>       
>   <cc:attributionName>World Wide Web Consortium </cc:attributionName>
> </descriptorset>
> 
> And the most complex thing there is rdf:type which we've discussed and 
> decided what to do about. Do you need to understand RDF to process this? 
> Well, yes _if_ you want to understand the semantics of 
> http://creativecommons.org/ns#Work - but in a given application it may 
> be enough to know it's there without doing any parsing?
> 
> So right now I'm thinking we should not only restrict descriptor sets to 
> having child elements that have no child elements to avoid a lot of 
> semantic hassle, but we could do the same for attribution and obviate 
> the need to understand RDF at all to process POWDER at least at an 
> operational level.
> 
> What would we lose?
> 
> Well, we'd lose the ability to put anything other than simple RDF in the 
> descriptor set and that must surely mean a reduction in flexibility. It 
> also makes some things a little more awkward. We were happily expecting 
> all xx:Agent classes to be defined externally until Ivan said that the 
> W3C hasn't got a FOAF file so can he put it in the POWDER file itself. 
> So we made it possible... but, well, if we said no, sorry Ivan, it's 
> about time W3C had an RDF description of itself somewhere, would that be 
> a show stopper?

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

> 
> Let me summarise with a proposed resolution.
> 
> PROPOSED RESOLUTION: That the descriptor set and attribution elements in 
> a POWDER document may contain RDF properties that have either a literal 
> value or that use the rdf:resource attribute to point to an instance of 
> owl:Thing only. Arbitrary RDF may not be included ()in XML terms the 
> child elements of descriptorset and attribution must not have any child 
> elements).
> 

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?

Ivan



> Arguments for:
>  - The semantics are much safer
>  - It means that at an operational level, it
>    is possible to process POWDER without an RDF tool kit
> 
> Arguments against:
>  - It reduces flexibility
>  - It forces people to have or create a file that
>    describes themselves (using FOAF or DC terms)
> 
> WDYT?
> 
> Phil.
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0058.html
> 
> 
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf