Re: (Ref.: ISSUE-12: Conjunction and disjunction) Semantics of resource set definitions

A few small comments inline below

Andrea Perego wrote:
> 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.

I am certain that negation should be included and your example seems 
entirely intuitive to me. If, starting from the most significant 
portion, the resource is on the example.org domain AND is NOT on 
their.example.org, then it's in the Set. Easy.

[snip]
> 
>> [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.

Actually, no, it's OWL Full that does that. OWL DL is closed world (just 
more complicated than OWL Lite).

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

Which brings us back to owl:unionOf and example 2A?

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

I think these do apply to grouping by resource property. If the resource 
property in question is colour then you can have a white space separated 
list of colours. And I agree on the white space or | issue. But we're 
trying to find an alternative to using REs for those who don't like them 
and that is less error prone (noting that REs are always going to be 
supported).

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

OK, I misunderstood your thinking. I thought you were opposed to option 
1. Ah well.

Phil

Received on Monday, 14 May 2007 15:01:57 UTC