VOResource 1.1 internal Working Draft

[Markus Demleitner]

Dear Colleagues,

First a word from our sponsors:

           ==========================================
            Time is running out for Cape Town.
            If you have anything Registry-related
            to report (and this includes wishlists)
            please act *now* and tell 
            msdemlei at ari.uni-heidelberg.de

                                        Thank You.
           ==========================================

Then, I've prepared an internal working draft for VOResource 1.1,
available from volute (trunk/projects/registry/VOResource) and in
formatted form from 

http://docs.g-vo.org/VOResource.pdf

I had expected this to be a short, little thing, but the list of
changes has become fairly long, so in preparations for (hopefully
lively) discussions in Cape Town, I offer a short Q&A here.


Why?
====

Main reason: VOResource should be able to communicate DOIs (and
ORCIDs); also, since it's hard enough to make people provide good
metadata in one scheme (let alone two) VOResource should be as
aligned as possible (retaining backward compatibility) with
DataCite's core metadata scheme.

Secondary reason: There have been a few baked-in vocabularies (for
dates, relationship types, content levels, content types).  I'd
rather manage these vocabularies  independently of the standard, more
like SAMP mtypes or perhaps datalink prodcut types.


What?
=====

I've taken care that VOResource 1.0 documents don't become invalid.
Paul's new schema versioning scheme also helps.  There's one really
new element: altIdentifier, currently possible  in Resource and
Creator (where it could take DOIs/bibcodes or ORCIDs, respectively).

The second big change is conceptual: Whereas VOResource 1.0 claims
it's just a serialisation of Resource Metadata, we adopt DataCite
core as a second "upstream".

A bit more minor is removing the spin towards having interfaces with
several different versions within one capability; in VO practice,
versioning has moved to standardIDs, as has service discovery (which
was still envisioned to use capability/xs:type then years ago).

Here are other changes from the changelog:

* Adding a version attribute to vr:Resource for compliance with XML
Schema Versioning Policies

* The vocabulary of date/@role is now managed as a separate
resource; DataCite terms have been added to it, and the old 1.0 terms
deprecated.

* The vocabulary of relationshipType is now managed as a separate
resource; some DataCite terms have been added to it.

* Service/rights now is free text rather than the tree-term
enumeration.  In addition, it now has a rightsURI attribute,
DataCite-style.

* content/type is now xs:token rather than a special restriction.
The vocabulary is now managed as an external resource.
Consequently, the vr:Type type vanishes from the XSD.

* content/level is now xs:token rather than a special restriction.
The vocabulary is now managed as an external resource.
Consequently, the vr:ContentLevel type vanishes from the XSD.

* Now discouraging fixing standardID in VOResource extensions.
Also, removed indication that capability/@xsi:type should be used for
service discovery.

* Now allowing a Z timezone marker in UTCTimestamp, indeed
discouraging non-timezone use.  This is in line with OAI-PMH use.
Therefore, while technically changing the schema such that legacy
clients  might be confused, we do not expect incompatibilites.

* resource/description and capability/description are now xs:string
to enable simple plain text markup.

* Consequently, removing 1.0 default on interface/@version.

* Added advice about the use of creator.name

* Removed SOAP/WSDL example and a bit of the accompanying language.

* Section 3 needed some refactoring since the schema documentation
is now generated from the schema document.  To accomodate this, some
text manually embedded within the schema documentation had to be moved
out of the generated material or removed.

* While we still reference RM, it is now no longer informally
authoritative for VOResource (we'd have to change RM before we change
VOResource otherwise)

* References to the RM terms in the metadata definition dropped
(could add support in ivoates/schemadoc if we want them back).

* Strongly advising the use of the vr: prefix, removing some
duplicated advice regarding prefixes

* Removed example for deriving a SIA capability (this is now
in the document repository)

Most of these changes correspond to individual commits.  See

svn log http://volute.g-vo.org/svn/trunk/projects/registry/VOResource

if you want to dig in or check the actual textual changes.


And that's it?
==============

Unfortunately, no.  There's still some topics that I think we need to
work out (assuming the proposed changes find acceptance).

Here is a list of topics I'd like to discuss:

* Relax IdentifierURI?  There's a todonote in the text discussing
what I think we should do.

* Unify party-like entities (creator, contributor, publisher, contact)
to a single type?

* Do we want DaCiMeta contributorType?  This would require defining a
new type for contributor so we can have an @type (or @role)
attribute.

* What about securityMethod?  Do we now have a better idea how this
might become useful?  Grid?

* Language: Should VOResource say content must be in English?  Or is
that something Registry Interfaces should say ("if you want your
stuff to be in the VO Registry...")?  Or do we keep ignoring the
issue?

* Use URLs instead of terms from hardwired RDF vocabularies throughout?

* What procedure do we adopt for vocabulary changes?

* Should more things have altIdentifiers?

* Recommendations on what to do with "should be drawn from the IAU
Thesaurus"?

* Should we define a naming convention as to US/British spelling
(there's "Organisation", but my impression is that most tech names in
the VO are US spelling)?

* What about disallowing multiple accessURLs right now?  Last time I
checked, no actual Registry record used that, so technically we'd not
even be invalidating anything existing with that schema change.

* Have some way to mark up mirror/main site in interface so people
can manage mirrors in the VO Registry?


What next?
==========

Given this long list, I'm thinking of devoting an entire Registry
session to the VOResource makeover (of course, if people hand in lots
of additional requests for time in the Registry sessions, that's not
going to work out, but right now it seems perfectly feasible).

It would be great if as many people as possible could come there with
opinions and ideas.  If there was something you always wanted in
VOResource, this is your chance.

Remember: The next change to VOResource might be another then years
away.

After Cape Town, I'd like to quickly make this an actual Working
Draft.  It'd be great if the really big issues could be out of the
way by then, and perhaps we can have RFC before Trieste, so we could
already discuss RFC results there.


You're serious?
===============

Well, yes.  I feel a bit bad that these lists have become so long,
but then VOResource was, in its core, devised about 10 years ago.
Much in the VO and beyond has changed, and I have to say Kudos to Ray
and company that all that I think really needs attention is this
list of relatively minor points.

Thanks,

            Markus