OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: The RDF model *is* part of the problem

[ Lists Home | Date Index | Thread Index ]
  • From: Gabe Beged-Dov <begeddov@jfinity.com>
  • To: haustein@kimo.cs.uni-dortmund.de
  • Date: Thu, 02 Mar 2000 20:53:35 -0800

Stefan Haustein wrote:

> Currently, my main / only problem for using RDF as object
> serialization format is: Even if you can compare RDF to Java
> (or Delphi) interfaces, you cannot generate a consistent
> RDF schema producing readable RDF from two interfaces
> (or classes) automatically, if both interfaces are
> in the same namespace (package) having a common property
> name with different types.

Are you saying that the package namespace is preferable to the class
namespace for anchoring property names when mapping from Java to RDFS?
E.g., if the two classes com.foo.A and com.foo.B both have a field
named "bee", then the issue is that the bee property is overloaded
when bound to the com.foo namespace?

I also wonder about the distinction between Java interfaces and
classes as far as serialization. Vilya has made a point of noting that
David talked about Interfaces rather than Classes when explaining the
mapping to RDF. If you were talking about data-centric interfaces that
used the JavaBean naming patterns that would make sense. Still, I
think it makes it more confusing than more straightforward examples
that use a data-centric class directly. 
> In RDF schema, property names are global. In OOP, object
> properties are local to the defining class/interface.
> Thus, I would need to add the class name to the property
> name in order to avoid possible problems with name
> conflicst. I also could assign a new namespace to each
> interface or class. But both alternatives make the RDF
> code very ugly...

Why does the use of a namespace/schema per class make the RDF code
ugly? We are used to large grained schemas that mix together many XML
components. This may be convenient when authoring schemas by hand. It
doesn't map well to machine processing and the ability to do component
level mixing and matching. 

Cordially from Corvallis,

Gabe Beged-Dov


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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS