OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [tm-pubsubj] Call for vote on new deliverable structure


Lars Marius

With some delay, I know will address the content of your arguments.

> I haven't had time to look into this yet, but could you explain why
> you would like to split this deliverable out from the original first
> deliverable?

My view on this has somehow matured. I think having a document gathering clear definitions
and *minimal requirements* that publishers could easily meet is important to start the
process of adoption of PSIs. As we have figured several times lately, there is a huge
available legacy of identifiers that can be used almost *as they are* as PSIs, because
they already meet those minimal requirements. It's important that people figure that those
valuable PSIs already exist, that they meet the minimal requirements, and do not
necessarily need heavy new process of publication, maybe just a little furbishing.

> To me it sounds as though the first deliverable will contain very
> little in the way of real substance ...

Yes, there will be "very little" substance in that first deliverable, and that's exactly
what we need. The less we have there, the better we are, because it will show that making
a PSI is very simple if you want to just meet requirements, and that requirements are very
few for PSIs to start to work. All the rest : format, structure, metadata, management, use
... is optimization, and I consider now it should stay at the level of recommendations and
best practices, with no requirements in it.

We have to pay much attention to what Suellen and/or Mary said about the publishing and
library universe. They want something simple, and we have to show them that they are
almost there, and don't need to pass through pages of arcane requirements to begin to set
and use PSIs.

> ... but that it will imply that we
> know what to do in the second deliverable.

No, if we consider documentation structure, format and metadata as only recommendations
and not requirements. See my proposal in other message, I would like now to have only this
first part to contain requirements, and the three others (Documentation, Management and
Use) to contain only recommendations and best practices

>  If we publish deliverable
> #1 first, that implies to me that we can't go back and change it. So
> we shouldn't freeze it before we know what we'll do in deliverable
> #2. But if we *do* know what to do in deliverable #2 why don't we just
> do that at the same time?

If Part 1 is requirements and Part 2 is only recommendations, then they have to be
separated.

> I don't see the point of this proposal.  Several times already I've
> seen people look at the current recommendations and be disappointed
> because there is so little there.  Now we seem to have decided that
> the first deliverable is to contain almost nothing, and I don't think
> that's a good idea.

I disagree. A PSI is *almost nothing* indeed if you stick to basic requirements.
And our documents have to show that (and first we have to be convinced ourselves)

1. Basically, it's dreadly simple, and requirements are very few.
2. In the details, there are many ways to do it, and a lot of devilish things to consider
and care of, but none of them does impact really on the basic requirements.

> I think that we are very close to ready to move on from the basic
> principles that were agreed on in Barcelona and start on the real
> work, which is now scheduled to be deliverable #2. I fear that if we
> follow the proposed schedule we will

>  a) cause problems for ourselves by freezing a document containing
>   recommendations we don't understand the full implications of, and

I think we are now mature enough to cast in stone the basic definitions and requirements

>  b) cause more problems for ourselves by getting bogged down in the
>     practicalities of finishing and polishing that document, rather
>     than moving forward to the real issues and actually making real
>     progress.

I don't think we put the "real issues" at the same level. The real issue now is to have
something simple, available for the world to stand upon :)) For example we could push that
Part 1 to be an OASIS standard when it is adopted as a TC recommendation, but I don't
think the following three parts should.

Bernard

-------------------------------------------------------------------
Bernard Vatant
Consultant - Mondeca
www.mondeca.com
Chair - OASIS TM PubSubj Technical Committee
www.oasis-open.org/committees/tm-pubsubj/
-------------------------------------------------------------------




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC