- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 16 Jul 2008 15:36:24 +0200
- To: Phil Archer <parcher@icra.org>
- CC: Public POWDER <public-powderwg@w3.org>, Dan Brickley <danbri@danbri.org>
- Message-ID: <487DF958.7020407@w3.org>
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="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) > 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... [snip] > > 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 there:-) 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. > Indeed... > [..] > >>> >> >> 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 nevertheless! Ivan > > Thanks as always for your time and help. > > Phil. -- 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
Received on Wednesday, 16 July 2008 13:36:58 UTC