Re: slotted notation -summary

Dave Reynolds wrote:
> 
> Michael Kifer wrote:
> 
>> Possible approaches
>> -------------------
>> 1. At some point, Hassan proposed to use one syntax and give it different
>>    semantics in different dialects. This has a problem that it might
>> create
>>    confusion and has a big drawback in that it becomes awkward to have
>> > 1
>>    kind of slots in the same dialect.
>>
>> 2. Harold is trying to unify Psi-terms and relational slots (see
>> below) by
>>    adding special syntax (of rest-variables), but this has no good model
>>    theoretic underpinning and (as far as I can see) so far his proposals
>>    failed to capture both semantics correctly.
>>
>> 3. Gerd proposes to have one slotted syntax in the core and give it
>> one of the
>>    known semantics, which we as a group will identify as the most
>> important one.
>>
>> 4. This approach is not to have slots in the core and let dialects add
>>    their own slotted syntax. This way > 1 slotted syntax (with different
>>    semantics) is possible within the same dialect.
>> 5. This approach is two have several different syntaxes and several
>> different
>>    semantics.
>>
>> Personal opinion (sorry for taking the liberty of injecting it here)
>> ----------------
>> I favor the 4th approach.
> 
> +1

+1

> 
>> Object-oriented slot notation:
>>           This semantics is used in F-logic, RDF, etc., and can also be
>>           simulated by choosing the appropriate constraints for OSF.
>>           Again, there are two things that one might say about slots in
>>           F-logic (and RDFS):
>>
>>       p(slot1->val1,...,slotn->valn)
>>             Here p is an object (as opposed to relation) and
>>         slot1(p)=val1, ..., slotn(p)=valn.
>>
>>       p(slot1=>typ1,...,slotn=>typn)
>>             Again, p is an object and this says that
>>         typeOfSlot1(p)=typ1, ..., typeOfSlotn(p)=typn.
>>         Similarly to the relational notation, it means that the
>>             values in p(slot1->val1,...,slotn->valn) must conform to
>>             the type spec in p(slot1=>typ1,...,slotn=>typn).
> 
> In RDFS/OWL that "must conform to" is not quite the same notion as in
> many object oriented notations, in RDFS/OWL it effectively means "does
> not contradict". The semantics license a deduction that vali is of type
> typi and only if one of vali's types is disjoint from typi is there a
> contradiction. Many object oriented systems have a stronger notion of
> type conformance.

In most RDFS/OWL systems the (RDF) data is seen as part of the logical
theory and is used, together with the axioms in the ontology, to deduce
(RDF) facts and logical axioms.

In many object oriented systems, as well as database systems, the data
set at hand is seen as one interpretation.  A typical task in such
systems is to check whether the data set is a model of the database
schema/ontology.
One could imagine doing the same thing with RDFS/OWL. There is nothing
in the RDFS/OWL semantics which prevents this, since both semantics are
based on the notion of a model.

Best, Jos


> 
> Further in some object oriented notations the signature is regarded as
> closed so that if you have:
>    p(slot1=>typ1, ... slotn=>typn)
> and then later see
>    p(slotz->valz)  (where z not in 1 .. n)
> that is an error unless you modify the signature to include slotz.
> In RDFS it is perfectly legal (and beneficial).
> 
> I don't know enough about F-logic to be sure whether it is identical to
> RDFS in these regards but in any case it seems that even within the
> object-oriented slot notion there is some variation of semantics possible.
> 
> Dave
> 
> 
> 
> 

-- 
Jos de Bruijn,        http://www.debruijn.net/
+43 512 507 6475      jos.de-bruijn@uibk.ac.at
DERI                      http://www.deri.org/
----------------------------------------------

Received on Sunday, 7 January 2007 23:07:10 UTC