Re: [Zope] - Documentproperties - XML/RDF
Jim Fulton wrote:
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.
Great !!!
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.
Yes and No The concept of documentmethods is very powerfull and I don't think one should do anything to cripple this concept. But I think that RDF can be a very powerfull extension in terms of attributes (not content). I like to view the documentobject as a pointer to content and methods for dynamicly creating presentations of content. However RDF elements (attributes) can extend the documentobject with meta-data, which is extremly important in applicatons for information-retrieval.
I expect that most "content" objects will allow more or less arbitrary properties.
This can be true if the documentobject entirely should implement the XML and DOM architecture, which probaly is much more complicated (?) since it probally rocks the whole objectmodel in Zope.
- 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.
When we're talking about meta-data that is. And yes that would be very nice.
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 think you guys are doing a tremendous job already, but of course one always begs for more. :)
- 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> ...
Embedding RDF-data in the head-tag is not considered "good practice", but as long as not all browers support XML-RDF we really should have this option.
- 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.
I don't think so. According to the RDF specification schema's er referred to in the RDF. A schema is just a textfile, like the one attached (for the Dublin Core). So, I think we need an RDF (python)object which dynamically configures itself according to a schema.
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).
Yeah, like the propertysheet for folders.
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.
Isn't it easier to let DTML take care of that?
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"?
In the system I'm designing I want a systemadministrator to make such decisions and not the individual user.
- 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.)
See above
Hope these ramblings are helpful. Comments are welcomed.
Jim
Thanks a lot sofar Jim, and I hope my comments will be of use. Wiebe Kunst
Wiebe Kunst wrote:
Jim Fulton wrote:
(snip)
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.
Yes and No The concept of documentmethods is very powerfull and I don't think one should do anything to cripple this concept.
The current DocumentClass will be renamed to "DTML Method". There will be a new class, "DTML Document", that is meant to be content. We won't be taking any functionality away.
But I think that RDF can be a very powerfull extension in terms of attributes (not content).
Right. My point is that RDF may be more important for "content" objects than methods.
I like to view the documentobject as a pointer to content and methods for dynamicly creating presentations of content.
Maybe I'm missunderstanding you. Are you talking about objects that behave like the current Zope objects? Or are you talking about some other thing that has rich multi-part content (as is currently handled with Folders)?
However RDF elements (attributes) can extend the documentobject with meta-data, which is extremly important in applicatons for information-retrieval.
Yes.
I expect that most "content" objects will allow more or less arbitrary properties.
This can be true if the documentobject entirely should implement the XML and DOM architecture, which probaly is much more complicated (?) since it probally rocks the whole objectmodel in Zope.
I don't follow this. What's the big deal in providing objects arbitrary properies? What does this have to do with DOM or XML?
- 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.
When we're talking about meta-data that is. And yes that would be very nice.
Right. (snip)
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> ...
Embedding RDF-data in the head-tag is not considered "good practice", but as long as not all browers support XML-RDF we really should have this option.
The RDF spec mentions embedding RDF in resources as one distribution option.
- 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.
I don't think so. According to the RDF specification schema's er referred to in the RDF. A schema is just a textfile, like the one attached (for the Dublin Core). So, I think we need an RDF (python)object which dynamically configures itself according to a schema.
We misscommunicated. My main point is that we need to identify what schema a property belongs to. Of course, we might *also* provide tools for creating schemas interactively. This could actually be quite useful. But that's secondary. (snip)
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.
Isn't it easier to let DTML take care of that?
How? There will be many contexts in which one will want to get D.dc.title. I don't see FTML being a solution. (snip)
- Should there me a way of saying: "I want all of the Dublin Core Properties"?
In the system I'm designing I want a systemadministrator to make such decisions and not the individual user.
By user, I meant the person managing the document. 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 (2)
-
Jim Fulton -
Wiebe Kunst