- From: Samuel Yang <syang@peoplemoverinc.com>
- Date: Thu, 9 Mar 2000 11:59:12 -0800
- To: "'alison@cee.hw.ac.uk'" <alison@cee.hw.ac.uk>, caro@Adobe.COM
- Cc: www-rdf-interest@w3.org
The following is the abstract of a presentation that I was supposed to give (entitled "Using RDF for Data") at XTech 2000 last week. I was told at the last minute by our legal department that I couldn't give the presentation because we are in the "quite period" before going IPO. However, I am attaching below the abstract of the talk, since it has already been made public. Paragraph 6 briefly describes the canonical form of RDF/XML that we use (fully conformant to RDFMS 1.0) and how we are using XSLT to tranform that RDF/XML into DHTML. Samuel C. Yang Senior Software Architect Opus360 Corporation - West Coast Office (formerly PeopleMover, Inc.) 1500 Rosecrans Avenue, Suite 310 Manhattan Beach, CA 90266 Putting People and Projects Together (sm) Ph: 310-819-1900 x127 Fx: 310-819-1901 Email: syang@peoplemover.com <mailto:syang@peoplemover.com> Web: www.peoplemover.com <http://www.peoplemover.com> ======================================================================== This presentation will show how PeopleMover has successfully used RDF throughout our n-tier thin client framework to represent, transport, and manipulate all data, not just metadata. I will also present information about our RDF Java library, and describe the features that make it ideal for those purposes. The RDF data model is essentially the same as the relational data model. We are able to automatically generate a RDF schema from a DB table's metadata, and then automatically map any row in that table to an equivalent RDF resource description that conforms to the generated RDF schema. We are also able to go in the opposite direction to create, update, or delete rows in the DB using RDF data that conforms to the generated RDF schema. Each RDF resource (r) that corresponds to a row in the same DB table (T) has the same generated URI namespace. However, the local part of each r's URI is different, and is based on the primary key value of the corresponding row in T. Also, we map each column name in T to a unique RDF property name shared only by the r's that represent rows in T. Whenever the DB model changes, we use a DB-to-RDF metadata tool to generate a new equivalent RDF schema, and store it in an RDF/XML document. The generated RDF schema contains metadata to describe every table, every column, and every relationship. At system startup time, a DB metadata service reads that RDF/XML document and caches its information in memory. Another DB service can then accept requests with RDF/XML arguments, and perform the appropriate CRUD (create, read, update, or delete) operations on the DB with the help of the cached DB schema. We also use XSLT to transform RDF/XML into DHTML. However, to ensure that we can do so, our RDF library generates RDF/XML that has a (perfectly legal) RDF syntax that satisfies a simple constraint. That constraint is: a RDF resource must be physically represented "one-level-deep". That is, any property value that refers to another resource must do so using the rdf:resource attribute. Resources cannot physically embed other resources. This constraint is required for at least two reasons: (1) this ensures that any RDF graph can be represented as an XML tree. All cycles in the RDF graph are physically broken, but are logically maintained through URI references. Without this constraint, a cycle can cause a tree of infinite depth. (2) XSLT stylesheets do not have to "understand" the full RDF/XML syntax, and can make very simple assumptions about the structure of the RDF/XML document: (a) Every RDF resource is an immediate child of the RDF/XML document's document element; and (b) A property's value is given by either literal (i.e., purely textual) content, or by a r:resource attribute. Our RDF library, PmRdf, is written in Java, and uses the collections library (either the JDK 1.1 or 1.2 versions) to efficiently store and handle the RDF data. PmRdf parses RDF/XML documents using the W3C SiRPAC parser, and can therefore "import" RDF/XML documents that are not "one-level-deep" into a PmRdf object. However, the library always "exports" the data from a PmRdf object into RDF/XML that is "one-level-deep". An instance of any resource or property can be obtained in constant time by providing its URI. PmRdf has a very extensive API, and also supports RDF containers. Although designed to be a generic RDF API, it has proven to be very easy and efficient to use for our specific data manipulation needs. Sam -----Original Message----- From: alison@cee.hw.ac.uk [mailto:alison@cee.hw.ac.uk] Sent: Thursday, March 09, 2000 1:38 AM To: caro@Adobe.COM Cc: www-rdf-interest@w3.org Subject: Re: XSLT applied to RDF? > > Has anyone toyed with applying XSLT transformations to RDF to generate > alternative representations? For example, the simplified "Just The I toyed with this last summer, to eliminate alternative abbreviated syntaxes to make subsequent use of XSLT to present (simple) RDF simpler. (Written up as paper for WWW9). I started writing a "normalising" XSLT stylesheet for RDF, but got bored/ran out of time. For my purpose I needed a canonical non-abbreviated syntax to make presentation/transformation of non-parsed RDF simple. Alison
Received on Thursday, 9 March 2000 15:01:01 UTC