[Zope] - Documentproperties - XML/RDF

Sat, 9 Jan 1999 02:18:55 +0100

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