Re: [CODE4LIB] [Fwd: Fwd: [DC-GENERAL] DCMI News 3 November 2008]

[Thomas Baker]

On Thu, Nov 06, 2008 at 04:03:01PM -, Stephens, Owen wrote:
> > In addition to DC-TEXT [1], there is a MoinMoin wiki syntax
> > for embedding DSP constraints into a human-readable wiki
> > document in a form that a script can extract to XML [2].
> > To see this applied to the Eprints profile [3], run the
> > script DSP2XML [4].  The source code is available at [5].
> > 
> > Tom
> > 
> > [1] http://dublincore.org/documents/dc-text/
> > [2] http://dublincore.org/documents/2008/10/06/dsp-wiki-syntax/
> > [3] http://dublincore.org/architecturewiki/EprintsApplicationProfile
> > [4]
> >
> http://dublincore.org/architecturewiki/EprintsApplicationProfile?action
> > =DSP2XML
> > [5] http://dublincore.org/documents/2008/10/06/dsp-wiki-
> > syntax/DescriptionSetProfile-dist.zip
> 
> Very neat - but it seems the reverse of what I'd instinctively look to
> do - that is, start with an XML version of the DSP and then integrate
> into a human readable environment?

DCMI does that with the documentation for DCMI Metadata
Terms; XML source is used to generate fresh Web pages and
RDF schemas whenever a term is added or changed.  However,
these documents and schemas are meant to be edited by just
one person and periodically published as archived snapshots.

The idea behind focusing on the wiki document was to make it
easier for people to work on the development of application
profile collaboratively.  Because everything outside the
embedded brackets is ignored in generating the XML, people are
free to add notes or strike-throughs, and they can use the
readable wiki diffs to see what's being changed.  The idea
is to help people move from a readable draft to prototype
without having to move everything out of the collaborative
editorial environment.

Tom

-- 
Tom Baker <[EMAIL PROTECTED]>

Re: [CODE4LIB] [Fwd: Fwd: [DC-GENERAL] DCMI News 3 November 2008]

[Thomas Baker]

On Wed, Nov 05, 2008 at 08:56:38AM -0800, Karen Coyle wrote:
> >On the otherhand, you clearly do need a human readable version of the
> >standard - if we talk about library cataloguing, you don't want to give
> >a cataloguer a copy of the DSP to refer to, but something a bit more
> >(human) usable, which I'll call the 'manual'. It seems to me that
> >ideally this 'manual' combines information from the DSP (in a human
> >readable format) with the usage guidelines, and that the usage
> >guidelines should not repeat information already encoded in the DSP. I
> >suppose what I'm thinking of is establishing something like 'good
> >practice' for the usage guidelines, and that these would say 'do not
> >repeat information that is already encoded in the DSP'
> >  
> There is some discussion about figuring out a way to embed the DSP in 
> the guidelines document (or vice versa) in a way that the two are really 
> one document with some machine-actionable code and some human-readable 
> guidelines. The SWAP document heads in this direction, I believe:
>  
> http://www.ukoln.ac.uk/repositories/digirep/index/Scholarly_Works_Application_Profile
> 
> See the link "note about DC-text format" near the top of that document. 
> f(http://dublincore.org/architecturewiki/DCText)

In addition to DC-TEXT [1], there is a MoinMoin wiki syntax
for embedding DSP constraints into a human-readable wiki
document in a form that a script can extract to XML [2].
To see this applied to the Eprints profile [3], run the
script DSP2XML [4].  The source code is available at [5].

Tom

[1] http://dublincore.org/documents/dc-text/
[2] http://dublincore.org/documents/2008/10/06/dsp-wiki-syntax/
[3] http://dublincore.org/architecturewiki/EprintsApplicationProfile
[4] 
http://dublincore.org/architecturewiki/EprintsApplicationProfile?action=DSP2XML
[5] 
http://dublincore.org/documents/2008/10/06/dsp-wiki-syntax/DescriptionSetProfile-dist.zip

-- 
Tom Baker <[EMAIL PROTECTED]>