Sorry about this but I posted a new message before I received this one with another suggestion.
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.
OK, I didn't get that
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)?
As far I have understood the specifications will XML in a broad sense deal with content. RDF is an XML application dealing with meta-data. One can say that the behavior of folders in Zope can resemble meta-data attributes and that those refer to other content.
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?
see above
- 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.
Thats right but some purists define it as "bad", but as I wrote since there aren't any browers supporting XML/RDF yet there aren't many other obtions if the client-side wants to do anything with RDF-data. I think our confusion is about this; I'm mainly concerned with using meta-data on the serverside (by means of DTML or other scripts for the purpose of classifying and information-retrieval. Maybe I should have stated this earlier on. Sorry.
- 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.
Maybe I haven't understood the specs correctly. What I mean is that a schema defines all the attributes on a propertypage.
Of course, we might *also* provide tools for creating schemas interactively. This could actually be quite useful. But that's secondary.
That would be lovely
(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.
You're right (once again) when the client-side wants to process meta-data.
(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.
Perfect Wiebe Kunst