[Zope] - Documentproperties - XML/RDF
Wiebe Kunst
Wiebe Kunst" <wkunst@eunet.no
Sat, 9 Jan 1999 00:12:48 +0100
This is a multi-part message in MIME format.
------=_NextPart_000_00B6_01BE3B64.CA537CB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>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
------=_NextPart_000_00B6_01BE3B64.CA537CB0
Content-Type: text/plain;
name="schema.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="schema.txt"
-- Dublin Core Schema
--
--=20
DublinCore attribute
description url 'dublincore.html'
prefix 'DC'
label 'Dublin Core'
icon <DublinCore.gif>
syntax container
attributes set
Title, Creator, Subject, Description, Publisher,
Contributor, Date, Type, Format, Source,
Identifier, Language, Relation, Coverage, Rights
Title attribute
description 'The name given to the resource by the creator or =
publisher.'
label 'Title'
syntax string
schemes
'Main' type,
'Alternative'type
Creator attribute
description 'The person or organization primarily responsible for =
creating the intellectual content of the resource. For example, authors =
in the case of written documents, artists, photographers, or =
illustrators in the case of visual resources.'
label 'Author or Creator'
syntax string
schemes
'PersonalName' type,
'PersonalName.Address' type,
'CorporateName' type,
'CorporateName.Address' type
Subject attribute
description 'The topic of the resource. Typically, subject will be =
expressed as keywords or phrases that describe the subject or content of =
the resource. The use of controlled vocabularies and formal =
classification schemas is encouraged.'
label 'Subject and Keywords'
syntax string
schemes
'LCSH' scheme
Description attribute
description 'A textual description of the content of the resource, =
including abstracts in the case of document-like objects or content =
descriptions in the case of visual resources.'
label 'Description'
syntax string
Publisher attribute
description 'The entity responsible for making the resource available =
in its present form, such as a publishing house, a university =
department, or a corporate entity.'
label 'Publisher'
syntax string
schemes
'PersonalName' type,
'PersonalName.Address' type,
'CorporateName' type,
'CorporateName.Address' type
Contributor attribute
description 'A person or organization not specified in a creator =
element who has made significant intellectual contributions to the =
resource but whose contribution is secondary to any person or =
organization specified in a creator element(for example, editor, =
transcriber, and illustrator).'
label 'Other Contributor'
syntax string
schemes
'PersonalName' type,
'PersonalName.Address' type,
'CorporateName' type,
'CorporateName.Address' type
Date attribute
description 'The date the resource was made available in its present =
form. Recommended best practice is an 8 digit number in the form =
YYYY-MM-DD as defined in http://www.w3.org/TR/NOTE-datetime, a profile =
of ISO 8601. In this scheme, the date element 1994-11-05 corresponds to =
November 5, 1994. Many other schema are possible, but if used, they =
should be identified in an unambiguous manner.'
label 'Date'
syntax string
schemes
'ISO8601' scheme,
'Created' type,
'Issued' type,
'Available' type,
'Acquired' type,
'DataGathered' type,
'Accepted' type,
'Valid' type
Type attribute
description 'The category of the resource, such as home page, novel, =
poem, working paper, technical report, essay, dictionary. For the sake =
of interoperability, type should be selected from an enumerated list =
that is under development in the workshop series at the time of =
publication of this document. See =
http://sunsite.berkeley.edu/Metadata/types.html for current thinking on =
the application of this element.'
label 'Resource Type'
syntax string
Format attribute
description 'The data format of the resource, used to identify the =
software and possibly hardware that might be needed to display or =
operate the resource. For the sake of interoperability, format should be =
selected from an enumerated list that is under development in the =
workshop series at the time of publication of this document.'
label 'Format'
syntax string
schemes
'IMT' scheme
Identifier attribute
description 'String or number used to uniquely identify the resource. =
Examples for networked resources include URLs and URNs (when =
implemented). Other globally-unique identifiers,such as International =
Standard Book Numbers (ISBN) or other formal names would also be =
candidates for this element in the case of off-line resources.'
label 'Resource Identifier'
syntax string
schemes
'URI' scheme,
'ISBN' scheme,
'ISSN' scheme,
'DOI' scheme,
'SICI' scheme
Source attribute
description 'A string or number used to uniquely identify the work from =
which this resource was derived, if applicable. For example, a PDF =
version of a novel might have a source element containing an ISBN number =
for the physical book from which the PDF version was derived.'
label 'Source'
syntax string
Language attribute
description 'Language(s) of the intellectual content of the resource. =
Where practical, the content of this field should coincide with RFC =
1766. See: http://ds.internic.net/rfc/rfc1766.txt'
label 'Language'
syntax string
schemes
'RFC1766' scheme
Relation attribute
description 'The relationship of this resource to other
resources. The intent of this element is to provide a means to express
relationships among resources that have formal relationships to others,
but exist as discrete resources themselves. For example, images in a
document, chapters in a book, or items in a collection. Formal
specification of Relation is currently under development. Users and =
developers should understand that use of this element is currently =
considered to be experimental.'
label 'Relation'
syntax string
schemes
'IsPartOf' type,
'HasPart' type,
'IsVersionOf' type,
'HasVersion' type,
'IsFormatOf' type,
'HasFormat' type,
'References' type,
'IsReferencedBy' type,
'IsBasedOn' type,
'IsBasisFor' type,
'Requires' type,
'IsRequiredBy' type
Coverage attribute
description 'The spatial and/or temporal characteristics of the =
resource. Formal specification of coverage is currently under =
development. Users and developers should understand that use of this =
element is currently considered to be experimental.'
label 'Coverage'
syntax string
schemes
'PeriodName' type,
'PlaceName' type,
'X' type,
'Y' type,
'Z' type,
'T' type,
'Polygon' type,
'Line' type,
'3D' type
Rights attribute
description 'A link to a copyright notice, to a
rights-management statement, or to a service that would provide
information about terms of access to the resource. Formal specification
of Rights is currently under development. Users and developers should
understand that use of this element is currently considered to be =
experimental.'
label 'Rights Management'
syntax string
------=_NextPart_000_00B6_01BE3B64.CA537CB0--