On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote: [snip]
With all this in mind, I just studied my Mozilla mimeTypes.rdf file again. At first, this file looks nasty. I've only defined handlers for two mime types, application/pdf and application/x-zope-edit, yet the string "application/pdf" shows up 8 times in the file! I only typed it once. ;-)
Good news, though, it's *really* compressible. :^) gzip can get 20-1.
But if I think of RDF files as database export files (or maybe the results of a database query), it all makes sense.
I hate to say it, but I can actually read RDF now.
- The order in which the RDF elements appear in the file doesn't matter, just like the physical order of inodes on a hard disk doesn't matter.With Mozilla, it goes one step further. A graph can have multiple datasources, which inject data into the graph. These datasources can get resources from different servers, from different kinds of content (IMAP, bookmarks, etc.)
Thus, not only does physical order not matter, but location doesn't matter either.
- The obvious way to read this file is to search for XML elements that look like '<RDF:Description about="urn:mimetype:*">'. But that's not the right way: that's like scanning filesystem inodes sequentially. Instead, there is a root URI, "urn:mimetypes", and the RDF elements make connections to other elements from there.That's right. The URN structure was a trap I fell into until very recently. I thought I would order my universe using a URN hierarchy. But I realized that it had no meaning and no use. When I next refactor, I'll move to a flat model of "urn:x-moztop:realmid:resourceid";, where the id's are immutable SHA calculations.
As an aside: Zope 3 should have an immutable, placeless object identifier, but I lost that debate on #zope3-dev pretty badly. ^)
The ids should have no meaning. All the meaning should go in the RDF properties, so you can do something with it.
This is another hidden meaning in RDF: properties are first-class resources, in addition to property values.
Lately I've been thinking more about distributed content management and mobile content management, so these kinds of things are more important for me. When you gather up a bunch of content from a bunch of loosely-coupled places, how do you make sense of it? If you have a document on your laptop and on your website, should they be considered the same logical document?
- RDF is hard to read, but legibility by humans isn't its primary focus. It's more concerned with providing a way to declare any relationship about anything.Right. That's what the graph tool at the W3C online validator is for. :^) Just throw it some RDF and let it draw a picture for you.
Good point. IMO, classic OODBMS want you to know more in advance than RDF. Also, the relationships are programmed, not assembled (perhaps that isn't clearly stated).The ad-hoc part is, for me, the key. Relational theory provided the theoretical foundation for modern online transaction processing. But things like content management are a much different problem. (One analyst states that unstructured content is 80% of the information in a business.)So RDF seems like a replacement for, or maybe enhancement of, relational theory. But I wonder how object-oriented databases fit in the mix?
RDF, in my view, is the equivalent of a "set theory", a formal foundation, for content management. Without it, everyone has to build their own "framework" for stitching things together, for connecting the dots.
Yes. There's the hard way and the easy way. For the hard way, you use XPCOM to grab the datasource, get a component to serialize it, and run some methods on it. (I say "hard way", really, it's probably 5 lines of JS. Long lines.)How do you (1) throw RDF into Mozilla and (2) get a dump of the results? Is there a utility for doing this?Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory.That's right. I've always been surprised when I threw some RDF/XML into Mozilla, then got a dump of the serialized results. What I put in doesn't look like what I get out. That's because there is an abstract model. The XML can look a couple of different ways, and you still have the same abstract model.
However, I'm using rdfds from XulPlanet (which is the best documentation site for any project I've ever seen):
http://www.xulplanet.com/tutorials/xultu/rdfds/
For a very quick and useful RDF introduction, read chapter six of the XUL tutorial:
http://www.xulplanet.com/tutorials/xultu/
With rdfds, getting a serialized version is simple:
var ds = new RDFDataSource("http://www.zope.org/some.rdf";);
alert(ds.serializeToString());
Are the results in RDF, and are they pretty much equivalent to "cat file1 file2"? :-)The result of serializeToString is indeed RDF, and it is not even close to cat file1 file2. :^) Logically it is exactly the same. The string itself, though, will look quite different than the two input files. The serializer can make up some URNs for anonymous resources, it can give new namespace prefixes to namespaces you declare, etc.
More important, it likes to rearrange...
Wait, that's more detail than you probably want. :^)
It took me a while, but I learned how to take advantage of this. With Moztop, I'm taking a pretty loose, distributed approach to content managment. I collect RDF from a bunch of different servers, throw it all into one big graph, and use this to draw widgets on the screen.I can see that the benefits on the client side would be enormous. For interfacing clients to Zope, we've always thought in two directions: either connect the client via ZEO, or have the client call remote procedures that return lists and strings. The ZEO client idea would be fast and easy, but the client would get unrestricted access to the whole database. The remote procedures would be secure but potentially slow, since the client usually needs more than one list or string.
The ability to make an assertion into a completely different part of the tree is something you can't do in XML.
This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product calledI will do everything in the universe to help such a project. How is that? :^)
I know what the practical benefits that RDF can mean for content management. And it isn't esoteric Semantic Gibberish. I'm unable, though, to map it on the server side. However, I'm having luck on the client side:
http://www.zope-europe.org/Members/paul/tmp/moztop-pinstripe.png
Right.
But if the client requests RDF using a remote procedure call, the server can send back everything at once that it considers relevant. Hmmm... but I bet there's more to it.Yes, but it's a good "more".
Right now I have a composite datasource (one that gets its data from multiple locations). It is getting fed by RDF from a CMF (where a page template serializes the entire portal_catalog) and from a Zope 3. Later I'll add a file system source. All of these generate resources and relationships that get thrown into a bucket.
I use a couple of RDF properties to hold things together: <nc:subitems> to indicated tree containment, <dc:title> and <site:resourcetype> (site is my own namespace) to provide connections into labels for the UI, and then CSS styling for icons and whatnot.
Here's a fantasy... the ability to write a template that can be processed either by Zope or by the client. When the client is able to do the work, send the template and bunch of RDF. When the client can't do it, preprocess it. This is what XSLT always wanted to be able to do, but I couldn't see it getting there. Maybe RDF can make this a reality? :-)If all you really want is to take data and draw stuff on the screen, XSLT can do it. However, XSLT, and I'm convinced the XML underneath, doesn't really help construct a complete interface. And certainly not one that is based on a rich content model.
This email is getting big, so I'll cut it off here for now. I'll study the XUL templates.
Cool. Drop by #moztop sometime and say hi. --Paul _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
