OAI-PMH works okay as a way of making publications available. This comes with OJS and I used it to link the ACS Digital Library to Arrow. This was in reply to Evan Arthur’s 2004 thought experiment .

Two things it brings to my mind (as this is just an off-the-cuff response from me, no comments on what the NLA should/will/can do!).:

1) The rules for the ARROW Discovery Service weren’t really designed to be a new standard, although obviously they implement some standardisation. They were designed purely to make the searching experience better. This may seem like a trivial distinction - some of the things are just information that we throw away, other things that we simplify, a change to de-emphasise the presentation of numbers in subject headings - but it gets at a broader point. Setting up a new standard isn’t easy - it needs to take into account, to the greatest extent possible, the needs of the community that are creating the data, and the myriad of possible ways that the data could be used. While the normalisation work done by the ARROW Discovery Service team is definitely a contribution to that, it isn’t really a new standard.

2) Some of this could be mediated by allowing a community to pick and choose which rules to apply. But I guess this gets to the point that I think is central: what we are probably looking towards is a series of mappings for different purposes, rather than just one mapping that produces “clean data”. For example, it is likely to be important for the government that authored peer-reviewed journal articles are identified. This shouldn’t necessitate that all repositories have a resource type that exactly equals this - it would be better if they could produce such items by a combination of three elements “authored” “peer-reviewed” and “journal article”. But they may need mappings that produce these outputs. Then a mapping designed for the Discovery Service may want a different level of subject granularity than one for a detailed subject gateway.

3) The hard stuff with standardising isn’t working out how to implement it. It’s managing to design a standard that is painless/relatively painless for the community to implement, and that has buy in. Then you have to maintain the thing. While I take Neil’s point about the problem being international, it does have a national dimension - funding for unviersities is nation-wide, and there is a national “community” of higher education institutions - it should be possible for that community to work out things like mappings and cross-walks and best practice - particularly if that will help institutions move towards meeting government requests.

But I’m under caffinated, so maybe I’m missing something obvious!

Firstly I agree with the bulk of your comments and ideas. However a couple of things need to be considered.
1. THE NLA currently has no long term commitment so far to maintain the ARROW Discovery Service and it is unreasonable to assume it will continue beyond the near future, say two or three years maybe.
2. Normalizing should be done at the local repository level as the OAI-PMH will be harvested by many end-user services. But, as you say who’s rules should be used and who will update and revise them?
3. Creating a national service sounds attractive but who’s going to provide long-term finanace, run and maintain it. It seems that we are prone to looking to/for a national solution i.e. The NLA when the problem is bigger and international in dimension.

A gold journal is 100% open access from the moment of publication, i.e. the journal itself provides open access (e.g. the PLoS journals).

A green journal does not provide open access (i.e., it charges a subscription fee) but permits authors to self-archive a copy of their article. In other words, the journal doesn’t provide OA but permits authors to provide OA to their work. The details of the journal’s policy (what the author is allowed to post, when, and where) are the source of the other colors in Sherpa Romeo. Most notably, some journals impose an embargo: authors are allowed to post a copy of their article online for free access, but only after a delay (usually 6 or 12 months after publication).

If you want to find a gold journal to submit your article to, try the Directory of Open Access Journal’s list of journals in library and information sciences.

For expanded views of the Linked Data Space just click on the Linked Data Explorer link in the page footer :-)

Kingsley

Totally Hoopy [1] Environment for …

[1] I’ll give you a clue - 42…

Faceted Architectured Solution for Content Inquiry via Network Access To Online Repositories

Five minutes thought over breakfast yielded this:

FAceted Solution for Controlled INquiry and Access To Online Repositories

*But*, in so far as I agree with TLLS that you can’t put a Fascinator on a Fedora (bizarre images notwithstanding), can I also proffer something you *can* put on a Fedora as an alternative?

Faceted Enquiry and Access To HEterogenous Repositories

Q. Would you allow authors to store their own modifications to the logic as different settings/referencing styles? This could allow authors to also use it for re-formating for different referencing styles and then give this to other users… maybe. Kind of like attaching a different ICE template to an existing ICE document but a bit smarter.

Q. Are you working on a paper for this?

Q. What happened to the pink?

Daniel.

Something along the lines of this, maybe:

http://tinyurl.com/5uqtam

Just to clarify, I’m not hacking away at Perl - not since the accident :) I’m just following along and throwing in my 5 cents (hoping it isn’t worth only 2 cents). I take a back seat to people who spend their days coding and not sitting in meetings.

Cheers, Duncan

Consider, for instance, that the institutional Web page of a submitter might be kept for one reason or another. A ‘hostname’ field would get you pretty far, but making the relation to the URI ‘http://xmlns.com/foaf/0.1/workInfoHomepage’ would let Vicki indicate that she means the kind of ‘hostname’ as Tim.

Since you’ll be creating the Fedora object, there’s an immediate opportunity to inject this into the RELS-EXT datastream, thus exposing it to the world, really, through the Fedora ResourceIndex. In doing so, we may be able to define the kind of values that have historically not been terrifically universal in the wide-open, schema-dependent world of VITAL/Fedora where unique or domain-specific information may live just out-of-reach of existing XML schemas. This would also let institutions have access to things like a cataloged DOI or ISSN without having to pull it out somewhat blindly from the descriptive metadata.

The payoff would be that any niche type of metadata can be exposed through the triplestore as a relation to the Fedora data object. This metadata is available to VITAL’s Velocity templates and can be integrated into the display alongside what’s considered the ‘canonical’ DublinCore/MARCXML/MODS descriptive metadata and would be, again, a relatively low-cost prospect with the nice side-effect of contributing to the still-nacent semantic content of the world.

More great stuff — thanks for taking the time to look so deeply into L8X. I’ve continued the thread on the PKP support forum:

http://pkp.sfu.ca/support/forum/viewtopic.php?f=15&t=3259#p12013

MJ

I started off with Freemind, but figured out that the tree structure in mind mapping isn’t what I wanted. I then started looking into Cmaptools, as well as ontologies. Freemind’s ability to expand/collapse and scroll I found lacking in Cmaptools. I eventually fell back to using a basic wiki with text, which is considerably less than I wanted to do … but I really should be focused on content rather than tools.

Along the way, considering SVG for the web, I looked at Inkscape for drawing. I discovered that OO Draw produces a subset of SVG when exporting, which means that OO Draw –> Inkscape is feasible, but Inkscape –> OO Draw is a mess. The final solution has there been to create and maintain diagrams in OO Draw, with a potential future of exporting to SVG when needed, and cleaning up that SVG in Inkscape.

On your suggestion, I’m going to have to look at Styles in OO Draw. I certainly use them in my writing (i.e. CSS on web pages), but hadn’t considered them on vector graphics.

If you don’t have the storage or bandwidth to distribute multiple versions of the same videos, I suggest uploading your videos to http://www.archive.org/ (The Internet Archive) which will create derivative format videos and host them for you at no charge. Many people serve gigabytes from archive.org and it works excellently.

Hey Peter, thanks — you got a couple of things wrong (see below) but I appreciate the comments. I’ve replied on the Lemon8-XML support forum in the hopes that it will draw the attention and interest of others.

http://pkp.sfu.ca/support/forum/viewtopic.php?f=15&t=3259

MJ

So I suspect we’re in furious agreement here…

The ODF TC was chartered in 2002 to create a standard for a set of formats for the interoperable interchange of documents among competing applications. Sun’s OpenOffice.org XML format was chosen as the beginning point and Sun staffers were made the chairman and secretary. But Sun steadfastly shot down nearly all proposals over the years directed toward making the formats vendor-neutral.

OpenDocument interoperability is a complete and utter myth constructed on the widespread misconception that an open format is necessarily an interoperable format. The situation is only slightly better than with MS Office because OOo is distributed under an open source license that allows other developers to clone its code base. But it is necessary to achieve non-lossy interoperability that everyone exchanging documents be using the same version number of the code base. With other ODF implementations, you may achieve non-lossy interoperability if everyone involved is using the same application and version of it.

Whether you experience data loss when there is a mismatch in applications or version numbers in the exchange depends on what ODF functionality is invoked at each end of the round trip with a particular document. If an OpenOffice.org ODF document uses an ODF feature that has no counterpart in KOffice, opening it in the latter will will not result in the same processing of the document because there is no corresponding feature in KOffice to map to. The same issue exists when going between earlier and later versions of OOo or its clones.

There are many other interoperability issues in ODF. Here is my current list of interoperability check points that both ODF and OOXML fail except as noted in the list. If you need assistance with vocabulary, you will find a helpful glossary at http://www.universal-interop-council.org/glossary

* Full-featured editors available that do not generate vendor-specific extensions?
* Interoperability of implementations mandatory?
* Interoperability between different IT systems demonstrated?
* Profiles developed and required for interoperability?
* Methodology specified for interoperability between less and more featureful applications?
* Specifies conformity requirements essential to achieve interoperability?
* Interoperability conformity assessment procedure(s) formally established and validated?
* Document validation procedures valid?
* Fully specified interoperability framework?
* Vendor-specific extensions classified as non-conformant?
* Preservation of markup necessary for interoperability mandatory?
* XML namespaces for incorporated standards properly implemented? (ODF-only failure because Microsoft incorporated only one relevant standard, XML 1.0)
* Optional feature interop breakpoints eliminated?
* Scripting language specified for embedded scripts?
* Hooks fully specified for use by embedded scripts?
* Portable cross-platform? (OOXML-only failure)
* Adequate cultural and linguistic adaptability?
* IPR restrictions absent?
* Vendor- and application-neutral?
* Capable of converging desktop, server, Web, and mobile device editors and viewers? (ODF-only failure but OOXML only within the context of the Microsoft stack)
* Responsiveness to market requirements for interoperability?

If anyone should tell you that ODF is designed for interoperability or is an interoperable set of formats, they are either ignorant, deliberately disseminating disinformation, or both. I will close with the words of Thomas Zander, a member of the ODF Technical Committee and lead developer of the KOffice KWord application:

“One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that’s useful to me and then save it and continue in KOffice without loosing lots of data.

“Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal[.]”

http://lists.oasis-open.org/archives/odf-adoption/200709/msg00032.html

if the web2 tool just means its blue with bits which are movable all good.

if it means youre co-athoring with the world then the forma dn ownership and dialogue and authoritative voice is different.
imagine if the raw data is single source v if it is crowd sourced via a bloom clock http://en.wikiversity.org/wiki/Bloom_Clock
you can see me flailing between the two modes when i was writing this in the wikiversity http://en.wikiversity.org/wiki/Talk:FLOSS_and_education

buried a long way back in this rambly conversation there are some of my thoughts on what i was doing wrong
http://alexanderhayes.com/Media/2008/podcasts/24042008_Janet_Hawtin_Alex_Hayes.mp3
largely not being confident and explicit up fron about what people could contribute and thinking through how to make collaboration work.

likely to be some interesting room for thought around sourcing data from different places and ensuring they are all apples and not some pears.
and also clearing copyright in collaborative contexts.

sound slike an interesting paper

j

Installed AbiWord on Ubuntu and tried it on a test doc. Indenting OK but does not respect ODT ‘restart numbering’ on lists. Some styles have come through OK but all list styles are in Standard style. Embedded photos not working. Document outline numbering attached to numbered heading style not showing.

Not suitable for use on ICE documents - clearly has shall we say ‘different’ ODF support from Writer.

I’d be interested to hear what kinds of documents work for you, but I can tell you that that for the documents I use which conform to a template that uses styles, including list styles (which is the only way in OOo to get consistent formatting for our purposes) KOffice does not work. Try it. KOffice does not support list styles at all so they get lost.

If you read the post I’m talking about degrees of support any data you could help out with would be very useful.

So I get the impression that you don’t have a clue, since KOffice, TextEdit, and AbiWord don’t share the OOO code base.

ZZ - A proud member of the ODF “cheer squad”

The people who have glanced at the OOXML standard and have said how bad it is for interop as well as how broken it is are standards experts, not members of the public of laymen like yourself.

As far as interop is concerned the problem with OOXML is that nobody other than Microsoft can implement it properly because of its broken and incomplete nature. On top of that, its brokenness means that even Microsoft hasn’t been able to implement it - the OOXML produced by the latest versions of MS Office are incompatible with the OOXML standard Microsoft submitted to ISO.

ZZ.

You’re right. The literature does not address this question. I only know what I know from experience at a small editing-and-typesetting-and-SGML service bureau in the late ’90s. When we got electronic documents, they were Word or occasionally LaTeX (which could be truly annoying because authors wouldn’t send their mods along so we couldn’t reconstruct their doc the way they intended).

Our internal processes — even the ones with SGML components — were based on Word as an editing and communicating-with-authors format. We were Penta-based, so we could straight-up typeset SGML. When we did that, though, the doc came out of editing in well-templated Word, then got run through a VB wringer and a lot of regular expressions to make almost-SGML, then the inevitable few handfixes (I got better at scripting these away eventually) and in the SGML went to Penta.

A way to get at this question sideways might be to survey journal submission requirements. Some say they accept Word/TeX/HTML/whatever, but my sense is a pretty hefty majority insist on Word. Those that actually offer a template are almost entirely Word. In the last couple years I’ve written a book chapter, half a book, and two articles, and I’m on tap for a third article shortly. All asked for Word.

Dean, what makes me wonder is this: if you want to focus on a format in which your data will last, then what chance does OOXML has ? When it is only implemented by 1 vendor, who has a history of changing formats to delibaretly break compatibility with every new version of it software.

Pete is right, ODF is not perfect, there is a lot of work to be done — especially in the area of wider software support for it, but at least it is started in the right direction. Which is far more than what we can say about OOXML. The problems of ODF are not a good reason to support something far inferior and purposefully broken like OOXML.

ZZ

I guess I (and possibly the IJDC journal editor, who uses Word and OpenOffice and OJS) could be interested in ICE. I did just take a look at the possibility of downloading it to give it a try, but I guess I’m a bit faint-hearted. Not only do I have to download ICE, I need Mac OpenOffice as well, plus a bunch of Word and OO templates. It looks a lot of work for a simple trial, and you can’t (apparently) yet produce me a NLM DTD XML-formatted document. I think the idea is great, love the “deposit” button, but don’t under-estimate how hard it is to persuade those behind the bleeding edge to give things a try, even if they start out willing…

Picasa for Win 98 doesn’t seem to have tagging at all that I could find and it doesn’t write captions back into EXIF metadata - I think the latest version does but that won’t run in OS X under wine, not for me anyway. The problem with it seems to be the media detector that needs to run as a separate process in the system tray.

Thanks for the comments and feedback, I’ll use them as motivation for future postings.

There are two main (and different) audiences for the add-in: authors and journal staff.

The demo was focused on the author experience, and, as you noticed, we try as much as possible not to introduce new UI. We try to keep the learning curve as low as possible, to simplify the authors’ experience, while being able to gather more structured content.

The other audience for the add-in is that of the folks in the back-end of journals: editors, copy editors, publishing workflow folks, and archive staff. This set of people have full access to the metadata that is a part of a NLM document (for those interested, we implemented this using InfoPath within Word). These folks have at least some knowledge of the NLM format or of its metadata requirements.

There is some interesting stuff going on at the template level, which would answer some of the points you bring up. The folks on the back-end will author templates for authors to download, and can incorporate rules into those templates.

In relation to the table in the Abstract, it was just convenient to use that section when doing the demo, but it indeed is valid to have tables there (http://dtd.nlm.nih.gov/publishing/tag-library/2.2/n-kx20.html):

“Such abstracts may be extensive, incorporating figures and tables.”

Feel free to drop by http://blogs.msdn.com/exscientia/ and let me know if you have additional feedback. I will be happy to continue the dialog, and try to address scenarios you bring up.

Lotus Symphony is OpenOffice 1.1.4, which IBM took private while OpenOffice was dual licensed under SSSL-LGPL. In October of 2007, after the incredilbly disastrous ODF Interoperability WorkShop held at the OpenOffice Conference in Barcelona, Spain, IBM commissioned Sun to fix Lotus Symphony. This was done under the guise of IBM contributing to the OpenOffice source code.

One of the funny events at the ODF Interop Workshop was the line of Sun OOo/SO developers walking up to the Lotus Symphony demo station and popping the OOo 1.1.4 easter egg - then walking away.

KOffice has been a member of the OASIS ODF TC for five years now, and the interop between KOffice and OpenOffice might as well be zero. At some point in time people are going to have to start wondering why ODF interop is so bad - especially among contributing members of the OASIS ODF TC!

My own take is that ODF suffers from the same application specific problems that will forever doom OOXML. The presentation layers of each format are entirely reflective of the application specific idiosyncrasies, feature sets and layout engines unique to the originating applications.

There were three areas of ODF 1.0 - ISO 26300 that were woefully un specified: numbered lists, formulas and the presentation (styles) layer.

When Sun submitted what was then Open Office XML to OASIS, the specification was clearly an XML encoding of the OOo/SO binary dump. It was not the clean slate so many now claim it to have been. The clean up of the spec began with an effort to thoroughly document the different packages (content, styles, metadata, settings, manifest). Once fully documented, the idea was then to genericize any application specific findings. Sad to say, but five years have gone by and the presentation layer in particular has yet to be fully documented, let alone cleaned to the point of application independence.

As for OOXML? Forget it. They make no bones about the fact that OOXML’s entire reason for being is that it’s application, platform and vendor specific.

There was a point in time prior to the open sourcing of OpenOffice when Sun considered writing a browser for StarOffice. One of the browser requirements would have been (X)HTML - CSS 2.0 compliance. This led to an intense discussion as to whether or not OOo/SO could produce read-write (X)HTML - CSS 2.0 formats useful to the browser. The decision was that this work would require a total rewrite of the OOo/SO layout engine. So the browser project was dropped.

Think of the impact this decision has had. XML itself does not have a presentation layer descriptive. W3C materials suggest CSS, XSL or XSL-FO to fill that void. CSS in particular is perhaps the most portable and universally interoperable presentation layer in use today. This however would have been a difficult and costly choice for Sun.

Because of the legacy layout engine in OOo/SO, Sun choose a uniquely application specific presentation layer called “automatic-styles” when they moved to develop an XML format.

Having lived through the ODF process since it began in October of 2002, i would have to say that the right way of doing an XML interchange format would be to write a clean room spec based on generic document structures - and without application vendor participation. Generic elements might have cascading attributes that begin with basic “must have” metadata moving into ever more complex (and application specific) descriptives. This way an interoperability - interchange base can be used to service simple applications without compromising the rich, full featured needs of complex productivity environments.

This stuff isn’t easy. But if “interchange” is the purpose, then we can’t allow a handful of legacy application vendors dictate design. Once the basic spec is in place, invite the vendors to run test implementations with feedback comments.

Oh wait! That’s how the W3C designs formats. They follow without exception the first law of the Internet: Interoperability trumps everything, and is never compromised. Including demands for innovation. Including demands for application, platform and vendor specific needs.

~ge~