- From: Andrea Perego <andrea.perego@uninsubria.it>
- Date: Mon, 14 May 2007 16:26:14 +0200
- To: Public POWDER <public-powderwg@w3.org>
Hi, Phil. > [snip] > > In your discussion, you suggest 4 possible solutions to the pathContains > issue. The complexities get more severe when we get into negatives and, > from my perspective, we're getting a long way away from a design > fundamental of simplicity with the real possibility that a > semi-technically minded person could write a set definition by hand if > necessary. I think here we should consider if and why we should support negation. It is not just to support as much flexibility as possible. As was reported in a previous version of the grouping document, negation is useful in order to simplify the specification of a scope by also supporting exceptions. Suppose, for instance, that a given DR applies to a set of hosts my.example.org, your.example.org, his.example.org, her.example.org, our.example.org, but not to their.example.org. If negation is not supported, the scope of the DR must be specified as follows: <wdr:Set> <wdr:hasHost>my.example.org</wdr:hasHost> <wdr:hasHost>your.example.org</wdr:hasHost> <wdr:hasHost>her.example.org</wdr:hasHost> <wdr:hasHost>his.example.org</wdr:hasHost> <wdr:hasHost>our.example.org</wdr:hasHost> </wdr:Set> otherwise, if a wdr:hasNotHost property is available, we can reduce the specification to <wdr:Set> <wdr:hasHost>example.org</wdr:hasHost> <wdr:hasNotHost>their.example.org</wdr:hasNotHost> </wdr:Set> So the issue here, is to find a way of supporting negation in a safe and possibly `intuitive' way. > Also, forgive me, but whilst all your examples are valid XML, they're > not all valid RDF since there's always the need for Class -> property -> > Literal/Class etc. (RDF heads like to talk about 'striping'). > > [snip] You're right, I apologize. I've used a sort of `colloquial' RDF, but, of course, we are on a W3C's mailing list... > [snip] NB. use of intersectionOf and unionOf requires OWL > DL, not OWL Lite - which gets us into more specialised inference engines. And, consequently, we may have undecidable resource set definitions (which is not a nice thing). The solution based on implicit semantics (if resolved properly) is safe also with respect to this issue. > [snip: implicit conjunction inside a resource set definition - wdr:hosHostList property] I don't completely agree. If we assume that all properties in a wdr:Set are always in end, saying "all the resources hosted by example.org and a path starting with foo or bar," will require two redundant resource set definitions: <wdr:Set> <wdr:hasHost>example.org</wdr:hasHost> <wdr:pathStartsWith>foo</wdr:pathStartsWith> </wdr:Set> <wdr:Set> <wdr:hasHost>example.org</wdr:hasHost> <wdr:pathStartsWith>bar</wdr:pathStartsWith> </wdr:Set> As you notice, this redundancy increases when we are talking of hosts, and not of path patterns, but I think that the need itself of repeating the same statement is far from being intuitive. I agree that it is preferable to combine *by default* all the properties in a resource set definition with the same Boolean operator, but the solution you propose has several drawbacks in terms of expressiveness. In other words, if we support AND (implicitly), we must support also OR (explicitly) inside a resource set definition. About the solutions to be used for this, I'm not comfortable with space separated lists as object of RDF properties (in such a case why not using a RE? we have just to substitute a blank space with a `|'). Also, we are forgetting here grouping by property. I'm not sure that the considerations above apply also to them. In other words, I'm for using RDF to express this. Of course, it may be verbose, not necessarily human-friendly, and require a lot processing. This is why I consider the `original' implicit semantics of resource set definitions (i.e., same properties in OR, different properties in AND) preferable, even though it is not formally sound. Andrea
Received on Monday, 14 May 2007 14:22:54 UTC