VOResource 1.1: Vocabularies, part 1

[Theresa Dower]

From the registry end, I'm for externalizing the vocabularies for these elements, as we spoke about in Stellenbosch. I'd strongly suggest keeping a suggested/shorthand list of the original terms in the VOResource document. This is trivial to do and helps folks who aren't necessarily inclined to delve so deeply avoid necessarily looking up these extra documents and getting more overwhelmed, which already sometimes happens with the existing VOResource architecture.

--Theresa

> -----Original Message-----
> From: registry-bounces at ivoa.net [mailto:registry-bounces at ivoa.net] On Behalf
> Of Markus Demleitner
> Sent: Thursday, August 18, 2016 4:46 AM
> To: registry at ivoa.net
> Cc: semantics at ivoa.net
> Subject: VOResource 1.1: Vocabularies, part 1
> 
> 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