[
Lists Home |
Date Index |
Thread Index
]
- From: Stefan Haustein <haustein@kimo.cs.uni-dortmund.de>
- To: james.anderson@mecomnet.de
- Date: Tue, 07 Mar 2000 13:32:21 +0100
james anderson wrote:
>
> facets don't sound like the right thing. they imply a semantic coherence
> where none is to be expected.
Do you have a better idea? For me, the best solution would be if
properties were defined always local to classes in RDF, similar
to all mainstream OOP languages. I do not say that RDF must
be restricted to the object model of common OOP languages, but
at least it should preserve backwards compatibility for
simplified migration. Since RDF allows multiple types per
instance, you could still add all properties you want
to an existing instance.
> > james anderson wrote:
> > > ...
> > > the "work-around" of "additional" namespaces is, well, the nature of the
> > > namespaces which java, in particular, prescribes. if rdf were to enforce
> > > these restrictions itself, then other oop forms wouldn't be serializable
> > > at all.
> >
> > Can you give a relevant example of this kind of OOP?
>
> The problem would arise in OOP forms where namespace structure is
> orthogonal to class structure. CLOS, for instance, is a oo-language in
> which slot inheritance is governed by rules for identifying names which
> are independant of the class inheritance structure. Names (symbols) are
> in packages and inheritance relations may be constructed among packages
> without regard to where the names appear.
So we have less problems for serializing a Lisp extension versus
more problems for Smalltalk, Delphi, C++, JAVA....
I do not think that will help RDF becoming widely used.
Best regards
Stefan
--
Stefan Haustein
University of Dortmund
Computer Science VIII
www-ai.cs.uni-dortmund.de
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|
