Re: [Zope] - Documentproperties - XML/RDF
Wiebe Kunst wrote:
Yes - thats exactly what I would like to achieve.
From: Jim Fulton <jim@digicool.com>
Let me try to express my understanding of your question by restating your question a bit.
You want to maintain the properties defined in the Dublin Core for Documents. That is, you want a Zope web interface for entering/editing these property values.
Further, you'd like to be able to generate RDF formatted text for these properties.
Am I on the right track?
First, the short answer is that supporting RDF is clearly the right thing to do. I'm not sure exactly when this will happen, although I can assure you that progress will be evolutionary. OK, then here are some initial observations/ramblings. - There is an emerging notion of "content", as opposed to "method" objects. Content objects are meant to contain information to be published. Methods OTOH are intended to be used to publish content but are not content themselves. I expect that most "content" objects will allow more or less arbitrary properties. - There should be a way to generate RDF text from content objects. In fact, there should probably be ways to generate RDF for any object and for various collections of objects. I assume that there are one or more reasonable mappings from the Python and Zope Object models to the RDF object model. Such a comprehensive effort is beyond my current bandwidth. :) - I propose to add a standard method for getting an RDF text from objects. I'm open to name suggestions for this method. For example, assume there is a method named ZRDF. You could get a RDF text for an object, a/b/c with a URL like a/b/c/ZRFD. You could also arrange to have the RDF embedded in rendered content. If a/b/c is a DTML Document (content) then you could have the head be something like: <head> ... <!--#var ZRDF--> </head> ... - There needs to be a way to define schemas (namespaces) for properties. There are a couple of issues here: o We need to be able to define schemas for properties. o We have to be willing to allow multiple properties with the same name, but different schemas. Alternatively, we need to be able to define distinct schema sub-objects that act like property "sheets". Hm. Maybe this is the right way to go. Maybe you can walk up to a content object and add a property sheet in which you specify a schema and the associated property values. This new property sheet then becomes an additional object view (accessed via a tab). From Python, properties in property sheets would be accessed through the property sheets. For example, suppose we had a document, D. Assume we've defined a property sheet, dc (for Dublin Core). To get the title defined by the dublin core, we'd use the expression: D.dc.title Note that property sheets might acquire. So, in the example above, if a value wasn't provided for title in dc, the standard Zope title would be acquired, perhaps after checking that the value was consistent with the dc schema. Maybe property sheets would have ZRDF methods to allow getting RDF for just one schema. o Maybe there should be a way to say that a single property value (e.g. title) should belong to multiple schemas/namespaces. This could be accomplished through acquisition, as described above. - For content objects, it seems reasonable that some extra effort should be made to support a standard simple meta-data schema, such as the Dublin core. I'm not sure how this should be accomplished in the user interface and I'm open to suggestions. For example: - Should there me a way of saying: "I want all of the Dublin Core Properties"? - Is it enough to allow any properties to be defined and leave it up to the user to decide which properties should be defined? - To what degree should properties be tied to specific schemas? How should users define or reference schemas? Should Zope have a tool that lets someone type in a URI for a schema and adds the associated properties to an object? Should there be RDF Schema objects in Zope that should support managing proport schemas? - Should there be schema-dependent property views? (Probably yes. See above.) Hope these ramblings are helpful. Comments are welcomed. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (1)
-
Jim Fulton