incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <murra...@altheim.com>
Subject Re: Metadata in 3.0 [Was: JSPWiki 3 design notes]
Date Tue, 05 Feb 2008 09:45:22 GMT
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

Mime
View raw message