I just read the RDF article published here: http://www.xml.com/pub/a/2003/02/12/rdflib.html I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. 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 called "RDFBucket"? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages. I'm wondering if I'm thinking in line with RDF theory, or if I've veered off track. If you're familiar with RDF: What do you think? Shane
I just read the RDF article published here:
http://www.xml.com/pub/a/2003/02/12/rdflib.html
I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction.
It is NOT just abstraction:) The point is you can read RDF and understand it, and machine can understand it too, what makes Web a huge database (of course in future). Its not just HTML or XML it is structured text, so for example you can search web - based on logic (like searching in library catalog), and not like to day - which is just matching words. In other words now you have content, RDF gives you content and metadata (content description). Ontologies are next step which gives you relation between objects and so on.
It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database.
Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory.
Semantic Web are based on RDF: One path might be (not only one): RDF -> DAML+OIL -> OIL -> Description Logics further for example FaCT -> ALC and so on.
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 called "RDFBucket"? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages.
1st idea: You can implement RDF almost in any SQL language, and be able to Query rdfs. 2nd idea: Besides any document in ZOPE can be RDF - special tags in html-header. On the other hand Plone uses Dublin Core, so you can easily make RSS (syndication), and RDF. But its limited to documents and basic Plone types. So you can, and Plone uses ZCatalog for searching 3rd idea: I haven't done research on RDF and Zope/Python, yet, but it seams to be a good idea to do something like "RDFBucket" especialy using ZODB (maybe not derivied from TinyTable). I also consider this idea but I would do it more like RDFS - Folder like object with (rdf) properties containing other objects (subclasses). This is about "5" minutes of programing. My consideration are going further - I'm thinking, about further develepment of this idea into OIL, DAML compatibile (restrictions, constraints), but I've to get check also OWL:)
I'm wondering if I'm thinking in line with RDF theory, or if I've veered off track. If you're familiar with RDF: What do you think?
Shane
Hope this gives you some light:) Lukasz
Lukasz Racon wrote:
I just read the RDF article published here:
http://www.xml.com/pub/a/2003/02/12/rdflib.html
I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction.
It is NOT just abstraction:) The point is you can read RDF and understand it, and machine can understand it too, what makes Web a huge database (of course in future). Its not just HTML or XML it is structured text, so for example you can search web - based on logic (like searching in library catalog), and not like to day - which is just matching words. In other words now you have content, RDF gives you content and metadata (content description). Ontologies are next step which gives you relation between objects and so on.
That's all fine and good, but I'd like someone to confirm my thinking: that the *core principle* of RDF is a new database abstraction. I believe that all the other concepts derive from this core principle.
It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database.
Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory.
Semantic Web are based on RDF: One path might be (not only one): RDF -> DAML+OIL -> OIL -> Description Logics further for example FaCT -> ALC and so on.
Please don't use so many new acronyms. DAML and OIL are weird enough. FaCT? ALC? I have no idea what you just suggested. :-)
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 called "RDFBucket"? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages.
1st idea: You can implement RDF almost in any SQL language, and be able to Query rdfs.
What does that mean? Do you mean that an RDF database could have a SQL query interface?
3rd idea: I haven't done research on RDF and Zope/Python, yet, but it seams to be a good idea to do something like "RDFBucket" especialy using ZODB (maybe not derivied from TinyTable).
I will not derive anything from TinyTable. That would not be pretty.
I also consider this idea but I would do it more like RDFS - Folder like object with (rdf) properties containing other objects (subclasses). This is about "5" minutes of programing.
I don't know what you're suggesting.
Hope this gives you some light:)
Right now, I'm looking for milk, not meat. :-) Shane
Good grief, how did I miss this!! Shane Hathaway wrote:
I just read the RDF article published here:
Yes indeed, that is a very good article.
I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database.
I think you are 100% correct, maybe 110%. :^) In the last two years I made several attempts at grokking Mozilla and RDF was always the wall I ran into that prevented further progress. In the last three months I slowly, surely, forced myself to study it. Write things down, take notes, rewrite them down, etc. The light bulb has definitely gone off for me now, and I see things exactly the way you describe it: 1) It's an abstraction. Once you start working with it, you realize what this means. You take a bunch of information and throw it into a bucket. You also throw in how the information relates to each other. 2) It's a database. You have a pretty formal way of asking questions and making sense of the stuff in the bucket. You also have a way to put things in the bucket, and also to rearrange the stuff in the bucket. 3) It's ad-hoc. You don't have to know everything beforehand like SQL. You also don't have to control the containment hierarchy like you do with XML. (Took me a LONG time to realize the significance of the latter point.) 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.) 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.
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. 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. 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 called
I 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
"RDFBucket"? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded
Yes, this is very similar to the client side model in Mozilla. I'm doing things like: o Assembling a hierarchy o Making up new hierarchies where none existed before o Generating property sheets o Doing conditional display o Making rich connections between loosely-coupled objects, meaning, objects that didn't expect to be coupled o Allowing data from Zope 2 and Zope 3 sites to be collected, presented, and related in the same interface Mozilla's template model is interesting to at least investigate. What's interesting about it is the way you can follow relationships in the model to draw things on the screen: http://www.mozilla.org/docs/xul/xulnotes/template-primer.html In this very simple example: http://www.mozilla.org/docs/xul/xulnotes/template-bindings.html ...note the last two resources shown in friends.rdf. Instead of repeating information in every "row", you get the equivalent of a join. Except the result of that join can produce another join. The template builder keeps following relationships. Also, you can join to something on another server.
RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages
I'm wondering if I'm thinking in line with RDF theory, or if I've veered off track. If you're familiar with RDF: What do you think?
You're on track, oh boy, you're on track. :^) To get this back into the world of the living, it would be helpful to think of a sample application. Here's one we all know very well: Collector/Tracker. Could you write a tracker system in RDFBucket without writing domain-specific objects? (Yup.) The nature of this kind of application is particularly well suited to your discussion. Another that is particularly well-suited: a Zope version of Microsoft Project, where you have Tasks, Resources, dependencies, etc. --Paul
Paul Everitt wrote:
Shane Hathaway wrote:
I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database.
I think you are 100% correct, maybe 110%. :^)
Whew, that's good to know.
In the last two years I made several attempts at grokking Mozilla and RDF was always the wall I ran into that prevented further progress. In the last three months I slowly, surely, forced myself to study it. Write things down, take notes, rewrite them down, etc.
The light bulb has definitely gone off for me now, and I see things exactly the way you describe it:
1) It's an abstraction. Once you start working with it, you realize what this means. You take a bunch of information and throw it into a bucket. You also throw in how the information relates to each other.
2) It's a database. You have a pretty formal way of asking questions and making sense of the stuff in the bucket. You also have a way to put things in the bucket, and also to rearrange the stuff in the bucket.
3) It's ad-hoc. You don't have to know everything beforehand like SQL. You also don't have to control the containment hierarchy like you do with XML. (Took me a LONG time to realize the significance of the latter point.)
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. ;-) But if I think of RDF files as database export files (or maybe the results of a database query), it all makes sense. - 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. - 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. - 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.
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.)
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.
So RDF seems like a replacement for, or maybe enhancement of, relational theory. But I wonder how object-oriented databases fit in the mix?
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.
How do you (1) throw RDF into Mozilla and (2) get a dump of the results? Is there a utility for doing this? Are the results in RDF, and are they pretty much equivalent to "cat file1 file2"? :-)
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.
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 called
I 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
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. 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. 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? :-) This email is getting big, so I'll cut it off here for now. I'll study the XUL templates. Shane
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.
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.) 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.
So RDF seems like a replacement for, or maybe enhancement of, relational theory. But I wonder how object-oriented databases fit in the mix?
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).
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.
How do you (1) throw RDF into Mozilla and (2) get a dump of the results? Is there a utility for doing this?
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.) 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. 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 called I 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
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.
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
Paul Everitt wrote:
On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote:
- 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.
Fascinating discussion. Could you please share the URL of this validator you mentioned? I am assuming it is based on GraphViz/IsaViz technology? Or is it something totally new? Thanks, --Craeg
On Friday, Feb 21, 2003, at 04:16 Europe/Paris, Craeg K Strong wrote:
Paul Everitt wrote:
On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote:
- 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.
Fascinating discussion. Could you please share the URL of this validator you mentioned?
http://www.w3.org/RDF/Validator/
I am assuming it is based on GraphViz/IsaViz technology? Or is it something totally new?
Nope, it is indeed GraphVis underneath. --Paul
Just a link:
- RDF is hard to read,
http://brownsauce.sourceforge.net/ -- Jean Jordaan http://www.upfrontsystems.co.za
On Thu, Feb 20, 2003 at 08:39:28PM +0100, Paul Everitt wrote:
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
For those of us who are noobs to this discussion, and to RDF in general, can you sum up what I'm looking at? and how this demonstrates RDF benefitting content management? -- Paul Winkler
Hi Shane In case your not aware Chandler OSAfoundation is basing their new PIM on RDF/ZODB/Python etc... if you haven't already it might be worth having a look at how they see RDF fitting into the picture. http://www.osafoundation.org/Chandler_rel._0.1.htm See ya Tim On Wed, 2003-02-19 at 03:21, Shane Hathaway wrote:
I just read the RDF article published here:
http://www.xml.com/pub/a/2003/02/12/rdflib.html
I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database.
Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory.
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 called "RDFBucket"? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages.
I'm wondering if I'm thinking in line with RDF theory, or if I've veered off track. If you're familiar with RDF: What do you think?
Shane
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
On 02/20/2003 09:06 PM, Tim Hoffman wrote:
In case your not aware Chandler OSAfoundation is basing their new PIM on RDF/ZODB/Python etc...
if you haven't already it might be worth having a look at how they see RDF fitting into the picture.
Wow, that's exactly what I was looking for. I guess I'll find out more when they open up their CVS. I hope it's soon. If they've had any difficulty persisting ZODB objects to RDF, I bet I could help them. Shane
Hi Shane Below is a posting from David McCusker who is working on the backedn of Chandler. =============================================================== From: Rys (David) McCusker <david@treedragon.com> Subject: Re: repository access protocol Re: [Design] Knowing when you've read Tim Hoffman wrote:
Any hints as to how RDF will bu used in conjunction.
that is one of the things that makes database design hard. Specifically, jumping through that hoop is one of the degrees of difficulty making the problem harder to solve. Additional degrees of difficulty include things like: *make it network protocol centric *make it fast and scale very large *use existing technology *write custom code for optimization *let the application coders see Python interfaces *make the local case faster than their remote case *make a centralized authorization case work *make the decentralized P2P good and attractive but that's just a sample. As you can see, it's hard to do justice to every priority. In many cases, we cannot give full-blown support to every iota of associated features one might think of in conjunction with one of the priority items. So we need some restrictions. In the case of RDF, we want to support it, and yet we do not want to compromise any of the priorities in pursuit of every feature folks associate with RDF usage. so our solution is that and RDF style application can see any of our content as if it was native to RDF. In other words, there is a mapping from our content to RDF. So you can get our content exported to RDF, among other things. Even more than this, some of Chandler application code wants to use RDF centric schema systems, with direct expression of this met information available at runtime. Katie has proposed a good an interesting system we will used to represent RDF meta information through python interfaces, by putting this information into classes, so RDF reflection features are visible as python APIs. However, consider some random feature of another RDF environment or application, call his feature X. we might not support X in Chandler -- at least, there might be no efficient way to do it, and we won't care. this means we do not aim to do every kind of RDF feature well in Chandler. We only aim to let the data we support the view in RDF terms. So there is a mapping in one direction outward to RDF, but there is not always a mapping the other way inward from RDF.
ie will RDF be used to map/find/query things in the repository?
we had not considered to using RDF specific query language so far in discussions. The repository access protocol will support more than one query language, and provide means to ask which one is supported in a given server. So in principle, a RAP server might use RDF in a query language and advertise this in the protocol dynamically. on the topic of query languages, we are not much further along than committing to more than one query language selectable dynamically at runtime.
and would this map to RAP access patterns ?
I imagine it's possible to implement some kind of RDF system which is implemented in terms of RAP, because RDF is notorious for making no guarantees about performance, so one might iterate over every data item in a database in order to satisfy an RDF query.
(probably not using the correct terminology here)
I'm not very particular about fashionable jargon as long as I understand what you mean. I prefer the informal approach to describing things anyway. -- Rys _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design On Fri, 2003-02-21 at 10:30, Shane Hathaway wrote:
On 02/20/2003 09:06 PM, Tim Hoffman wrote:
In case your not aware Chandler OSAfoundation is basing their new PIM on RDF/ZODB/Python etc...
if you haven't already it might be worth having a look at how they see RDF fitting into the picture.
Wow, that's exactly what I was looking for. I guess I'll find out more when they open up their CVS. I hope it's soon. If they've had any difficulty persisting ZODB objects to RDF, I bet I could help them.
Shane
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Shane Hathaway wrote:
On 02/20/2003 09:06 PM, Tim Hoffman wrote:
In case your not aware Chandler OSAfoundation is basing their new PIM on RDF/ZODB/Python etc...
if you haven't already it might be worth having a look at how they see RDF fitting into the picture.
Wow, that's exactly what I was looking for. I guess I'll find out more when they open up their CVS. I hope it's soon. If they've had any difficulty persisting ZODB objects to RDF, I bet I could help them.
Some points on this: 1) The Chandler folks had a lot of discussion on zodb-dev. 2) There is already a ZODB-backed storage for rdflib: http://rdflib.net/ 3) Andrew Kuchling has done quite a bit to integrate zodb, rdflib, and python: http://www.amk.ca/talks/semweb-intro/ (can't find the other links, but it's in the rdflib archives) 4) The next OSCOM conference, in Harvard this summer, will focus on the intersection between content management and semantic web. --Paul
participants (7)
-
Craeg K Strong -
Jean Jordaan -
Lukasz Racon -
Paul Everitt -
Paul Winkler -
Shane Hathaway -
Tim Hoffman