Re: shapes-ISSUE-11 (S9 impossible): S9 is about existing but unspecified values

Yes, exactly.  With the specific point that we consider "there must be a
value"  as a consistent extension of "no value is required"
(distinguishing, I guess, between "no value is permitted" vs. "no value is
required")

Dean


On Thu, Feb 12, 2015 at 10:45 AM, Irene Polikoff <irene@topquadrant.com>
wrote:

> So, the idea here is that there are some constraints for a Contract. Then,
> since a Bond is a subclass of a Contract, one doesn't need to repeat all
> these constraints, but could simply add an additional constraint specific
> to Bonds, but not to All Contracts - such as requiring a date.
>
> Correct?
>
>
> Irene
>
> Sent from my iPhone
>
> On Feb 12, 2015, at 12:46 PM, Dean Allemang <
> dallemang@workingontologist.com> wrote:
>
> The spirit of the original story is just the inheritance of further
> restrictions from "not required" to "required".  For a Contract in general,
> the end date is no required, but for a Bond, it is.   This is even
> summarized in the original wiki (I think by pfps) in the sentence, "The
> larger requirement here is restriction refinement in subclasses"
>
>
> From a Shapes point of view, I think it is correct to say that it is
> impossible to say, "An end date exists, but we haven't specified it" (that
> sounds like an open-world statement, and I think Shapes makes close-world
> statements).  If that is the aspect that is deemed "impossible" here, then
> I concur.
>
>
> My point in telling the story may be subsumed elsewhere; it is just that
> it should be possible to extend a shape that has no requirement for
> something being filled in (in this example, that's end date) by adding a
> requirement (e.g., in a sub-shape) that it does have to be specified (and
> perhaps has other constraints, e.g., end-date should come after
> start-date).
>
> This story was intended as an example; I would not be surprised if the
> principle for which it is an example has been stated more generally
> elsewhere.
>
>
> Dean
>
>
>
>
>
> On Wed, Jan 14, 2015 at 4:26 PM, Peter F. Patel-Schneider <
> pfpschneider@gmail.com> wrote:
>
>> The problem is that some of S9 appears to be asking for a constraint that
>> states that a contract can have a property value for its end date.  This is
>> different from the ICV constraint provided for bonds, which requires a
>> specified value for the end date.
>>
>> What would a constraint that required that it was possible to have a
>> value for a property look like?  What would it mean?
>>
>> peter
>>
>> On 01/09/2015 03:41 PM, Dean Allemang wrote:
>>
>>> The issue that S9 is about (as Peter outlines here
>>> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S9:_
>>> Contract_time_intervals)
>>> is that it should be possible to add constraints in subclasses where none
>>> existed above.  The ICV example on that page seems to address this quite
>>> directly; at one level, it doesn't represent a constraint, while at the
>>> next
>>> level down, it does.  The meaning of this might not be fully clear - I
>>> have
>>> added a paragraph to the description on the Stories page that I hope
>>> clarifies
>>> it.  Basically, it seems to me that the ICV code has got it right.
>>>
>>> So, far from being impossible, it seems that there is a solution
>>> presented
>>> right on the wiki.
>>>
>>> On Thu, Dec 18, 2014 at 7:10 PM, RDF Data Shapes Working Group Issue
>>> Tracker
>>> <sysbot+tracker@w3.org <mailto:sysbot+tracker@w3.org>> wrote:
>>>
>>>     shapes-ISSUE-11 (S9 impossible): S9 is about existing but
>>> unspecified values
>>>
>>>     http://www.w3.org/2014/data-shapes/track/issues/11
>>>
>>>     Raised by: Peter Patel-Schneider
>>>     On product:
>>>
>>>     Story S9
>>>     https://www.w3.org/2014/data-shapes/wiki/User_Stories#S9:_
>>> Contract_time_intervals
>>>     appears to require constraints that state that a property has a
>>> value but
>>>     this value is not specified in the graph.  Do any proposals cover
>>> this
>>>     requirement?  Is this a constraint at all?
>>>
>>>
>>>
>>>
>>>
>>>
>

Received on Thursday, 12 February 2015 18:53:29 UTC