VOResource 1.1: Vocabularies, part 1

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu Aug 18 10:45:40 CEST 2016


Dear Registry, dear Semantics,

In moving to VOResource 1.1, we have some topics touching Semantics,
so I'm cc:-ing semantics as a heads-up.  However, I'd suggest
(Registry-related) discussion to take place on the Registry list
rather than on both.

VOResource 1.0 managed some vocabulary-like term lists within the
schema.  This turned out to be a major pain on several occasions
(e.g., when we'd liked to have introduced a "uses"-relationship for
linking tools and tutorials, or when we wanted to consolidate content
levels to make them handlable); in particular with our old policy of
changing the target namespace when the schema content changes, each
vocabulary addition would have broken the entire infrastructure.

Even with our new namespace policy, a schema update is relatively
expensive, and many of the word lists can actually be used like
vocabularies, where nothing really breaks if new terms are
introduced.

Hence, for VOResource 1.1 [1] I propose to move the following elements'
content models from schema-constrained to vocabulary-constrained

 * content/contentLevel
 * content/type
 * relationship/relationshipType
 * date/@role

These are to be managed according to the rules currently developing
in the semantics WG.

Does anyone disagree with this general approach?

The individual vocabularies I'd like to discuss separately, except
for content/type -- this is just pulled straight from VOResource 1.0.
While I'd say that this piece of metadata hasn't been terribly
usefule in Registry practice it seems plausible that it might yet
become useful as the VO evolves.  And anyway, if we removed it, we'd
(at least in theory) have to bump the major version number, and that
we don't want.

But perhaps someone has good ideas on how to enhance it?

While it's still in development, the vocabulary is available 
Norman-style from
http://docs.g-vo.org/vocab-test/relationship_type/2016-08-17/relationship_type.html
-- Norman-style means that you can use the accept header to choose
between Turtle, RDF/XML, and HTML (which is the default and therefore
what your run-of-the-mill browser sees)[2].


Cheers,

         Markus


[1] In case you've just tuned in: A WG-internal draft of VOResource
1.1 is available from http://docs.g-vo.org/VOResource.pdf, or in
source from
http://volute.g-vo.org/svn/trunk/projects/registry/VOResource

[2] Yes, the HTML version isn't pretty.  In case you feel like a bit
of good ol' HTML+CSS, you'd be most welcome to improve appreances
in convert.py and friends; see
http://volute.g-vo.org/svn/trunk/projects/registry/VOResource/terms



More information about the semantics mailing list