Fabian,

I myself have three separate and very different JSPWiki applications
currently in mind, all with very different requirements and different
metadata schemas. Something like a Flickr system is certainly the
type of thing I can also see JSPWiki providing, i.e., somebody would
extend the system (likely with a modified metadata schema, some
plugins and some JSP work) and have an entirely new application. I've
already got about 90% of a digital library application written in a
way that's compatible with JSPWiki as the front end. There are many
possibilities.

Cheers,

Murray

Fabian Haupt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1

Hi,

I'd really like that approach. That way it would be easy to add( and
possibly edit) picture's metadata given in the various formats from
within the wiki. Using this one could easily implement, something like a
'picture management wiki', like for collaborative tagging of holiday
pictures with you pals.

greets
Fabian


Murray Altheim wrote:
| In looking at the 3.0 design document at
|
|    http://www.jspwiki.org/wiki/JSPWiki3Design
|
| I have some comments on the metadata plans. These comments are only
| tentative.
|
| ----
| ! Metadata Meta API
|
| Now, before getting into this too deeply it occurs to me that we might
| consider a pluggable meta API rather than single metadata schema. There
| are likely a variety of different applications that JSPWiki may be
| used within (simple wikis, embedded apps, hives, part of document mgmt
| systems, etc.), and we likely also want scalability (i.e., in terms of
| both simplicity/complexity and factors like page an revision count) in
| our metadata just as we do in other areas. I don't think this sounds
| particularly difficult if we're using a JSR-170 compliant repository:
| there'd be a core set of metadata fields whose actual descriptors would
| be assigned by the API implementation. If an application needed more
| than that it'd be up to the implementation to define and handle (e.g.,
| because the documents will be used within a more complex framework or
| document management system having an existing schema). We'd simply be
| creating the API and reference implementation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqBPJtC//DIQj2V8RAjoGAKCg+LCsTRc8VnGMvghNYR1HjrReRgCfVAv8
6ymmoWJV5B2SpcP+FzMFZxE=
=gX1L
-----END PGP SIGNATURE-----



--

...........................................................................
Murray Altheim <murray07 at altheim.com>                           ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

      Boundless wind and moon - the eye within eyes,
      Inexhaustible heaven and earth - the light beyond light,
      The willow dark, the flower bright - ten thousand houses,
      Knock at any door - there's one who will respond.
                                      -- The Blue Cliff Record

Reply via email to