Re: ASN issue: leaf class == visible class?

Boley, Harold wrote:
> Sandro, Yes:
> 
> inner class == invisible class
> 
> leaf class == visible class
> 
> -- Harold

I don't agree fully here...

> -----Original Message-----
> From: Sandro Hawke [mailto:sandro@w3.org] 
> Sent: Thursday, July 12, 2007 10:22 PM
> To: Boley, Harold
> Cc: public-rif-wg@w3.org
> Subject: RE: ASN issue: leaf class == visible class? 
> 
> 
> Harold, I'm not sure I understand what you're saying.  I think you're
> agreeing with my suggestion that we define things so that any ASN class
> which has a subclass is "invisible".  (That is, its name will never
> occur in a serialization -- we'll always serialize a subclass.) Is that
> right?
> 
>     -- Sandro
> 
> 
> "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca> writes:
> 
>>If we refine
>>
>>    class Naf
>>
>>to
>>
>>    class NAF
>>
>>       subclass StratifiedNaf
>>
>>	   subclass WellFoundedNaf
>>
>>	   subclass StableModelNaf

Hmmm, you mean to say that I need to specify which naf I use ALWAYS?
In this case we rather call the first class
     PerfectModelNaf
since this is what it is on the pure semantic basis. The perfect model 
semantics is simply only defined for stratified programs. Systems which 
implement it -- and it seems that there are no systems which only allow 
strat naf and do check is -- norlmally deploy perfect model semantics 
and just fault in case the program is unstratified.

To call it stratnaf sounds like stratnaf would be something *different* 
from well-founded or stable negation, which it is not in case the 
program is stratified. Why I wanted to have the subclassing in first 
place was because my understanding was that I wanted to express that in 
the stratified case both well-founded and stable coincide.

axel

>>NAF should become invisible assuming StratifiedNaf, WellFoundedNaf,
>>and StableModelNaf occur as subclasses of NAF only (understood if
>>ASN always assumes a subclass tree, not allowing a subclass DAG):
>>The unique NAF parent is just an 'interface' then, not part of the
>>serialization.
>>
>>Generally, making the 'class tree' assumption,
>>we can have subclass paths
>>
>>class TAG1
>>  . . .
>>  subclass TAG2
>>    . . .
>>    subclass TAG3
>>      .
>>        .
>>          .
>>          . . .
>>          subclass TAGN-1
>>            . . .
>>            subclass TagN
>>            . . .
>>          . . .
>>          .
>>        .
>>      .
>>    . . .
>>  . . .
>>
>>with N-1 invisible inner classes and 1 leaf class =3D=3D visible
> 
> class.
> 
>>-- Harold
>>
>>
>>-----Original Message-----
>>From: public-rif-wg-request@w3.org
> 
> [mailto:public-rif-wg-request@w3.org]
> 
>>On Behalf Of Sandro Hawke
>>Sent: Thursday, July 12, 2007 3:35 PM
>>To: public-rif-wg@w3.org
>>Subject: ASN issue: leaf class =3D=3D visible class?=20
>>
>>
>>
>>I've got an issue in the abstract syntax notation.  This e-mail is
>>perhaps more a brain-dump than a cogent argument or proposal; I hope
>>it's good enough.
>>
>>Let's call ASN syntactic classes with no declared subclasses "leaf
>>classes".  Let's call the others, with one or more declared subclasses
>>"non-leaf".=20
>>
>>Further, let's say a "visible" class is one whose name might be
>>transmitted as part of serializing an instance of it.  An "invisible"
>>class is one whose name will never be transmitted.  (Invisible classes
>>cannot be instantiated.  They correspond essentially to "abstract base
>>classes" and Java "interfaces".)
>>
>>The issue, then, is this: Shall we say Leaf and Visible are equivalent
>>classes?  I suggest "Yes".=20
>>
>>An example:
>>
>>    class NegationAsFailure
>>
>>         subclass StratifiedNAF
>>
>>	 subclass WellFoundedNAF
>>
>>	 subclass StableModelNAF
>>
>>Would we ever want to allow people to transmit something, saying just
>>that it is a "NegationAsFailure", but not saying which kind it is? =20
>>
>>I think not.  I think if we wanted that, we could do it more clearly
>>as:
>>
>>    class NegationAsFailure
>>
>>         subclass StratifiedNAF
>>
>>	 subclass WellFoundedNAF
>>
>>	 subclass StableModelNAF
>>
>>         subclass UnspecifiedNAF
>>
>>Looking at the current from Horn Dialect drafts:
>>
>>     class CLAUSE
>>    =20
>>        subclass ATOMIC
>>    =20
>>        subclass Implies
>>           property if: CONDITION
>>           property then: ATOMIC
>>    =20
>>     class ATOMIC
>>    =20
>>         subclass Equal
>>            property side: list of TERM
>>    =20
>>         subclass Uniterm
>>
>>... can you imagine wanting to subclass/extend Implies, Equal, or
>>Uniterm?  If so, would it be okay to make other changes so that it's
>>reasonable to have the extended class become invisible?
>>
>>If we need visibility to be independent from leaf-ness, then I think
> 
> we
> 
>>need to add an "invisible" keyword to ASN.  The drafts use
>>all-upper-case to indicate which classes are invisible, but that
>>shouldn't be what the software uses.)  I also need some way to say
> 
> this
> 
>>in OWL.  Maybe invisible classes are the same as
>>disjoint-union-superclasses?   Or can we just stay with =
>>Leaf=3D=3DVisible?
>>
>>Thoughts?
>>
>>     -- Sandro
>>
> 
> 
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Friday, 13 July 2007 12:33:55 UTC