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

Received on Friday, 13 July 2007 01:23:13 UTC