Re: ACTION-268

2009/1/22 Bijan Parsia <bparsia@cs.manchester.ac.uk>

> I don't understand this as a reply to my message or my action.


nothing to do with you.
the goal was to synthetize/homogenize  the documentation for the reply to
JH1 comment

Christine



>
> On 21 Jan 2009, at 23:00, Christine Golbreich wrote:
>
>  Regarding documentation  related to JH1 :
>>
>> 1) I can see that Boris had already extensively documented the 'named'
>> issue in the Syntax and added an example of non inference with no named
>> instance. The sentence below might be merged/moved to it.
>>
>
> ? My sentences is in the syntax.
>
> 2)
>> - the NF&R has already asserted  that a  haskey axiom only concerns named
>> instances of a class C as well:
>> "A HasKey axiom states that each named instance of a class is uniquely
>> identified by a (data or object) property or a set of properties"
>> - The example also stresses that a haskey axiom does not state that each
>> instance of the class C has at least one value for the key property
>> - As proposed at last TC, I have now extended the comment of the example
>> in adding the sentence "The inference that each patient who has a
>> a:hasWaitingListN belongs to the class a:RegisteredPatient cannot be drawn "
>> so as to make it clear that the inference of belonging to the class cannot
>> be drawn, which was, if I remember correctly, the initial point of the
>> discussion.
>>
>
> Again, nothing to do with my action.
>
> However, it misses the point. The commenter understood the semantics, just
> didn't see the rationale. The point of putting something in the NF&R is to,
> well, you know, document the rationale.


not only, an introduction that helps to grasp the new features as well


>
>
>  3) Moreover there is also an addition done by Michael  in RDF-Based Sem.
>> in section 5.14
>> "Keys provide an alternative to inverse functional properties (see Table
>> 5.13). They allow for defining a property as a key local to a given class:
>> the specified property will have the features of a key only for individuals
>> within the class, and no assumption is made about individuals external to
>> the class, or for which it is unknown whether they are instances of the
>> class. Further, it is possible to define "compound keys", i.e. several
>> properties can be combined into a single key applicable to composite values.
>>
>>
> Again, nothing to do with my action.
>
> Again, this merely documents but does not give the rationale.
>
> Cheers,
> Bijan.
>



-- 
Christine