Re: next

Rick, hello.

On 2008 Jan 21, at 13:27, Frederic V. Hessman wrote:

> - suggest keeping version info in the name of the vocabulary (rather
> than in the pathname, which might change without the vocabulary
> actually changing) - eg. "http://myvocab.org/myvocab-v1.1#mytoken"
> rather than "http://myvocab.org/v1.1/myvocab/#mytoken".

True, though this might be unnecessary inasmuch as it'd always be the complete namespace URI which is quoted. On one side, having the version number in the `filename' is convenient for people downloading the file; on the other, having the number further `up' the path name might be convenient in bundling together a number of separate files in a release. I think this could probably be handled as part of the minutiae of making the release.

> - suggest using either a "hash namespace" (e.g. "http://myvocab.org/myvocab-v1.1#mytoken
> "), a "slash namespace" (e.g. "http://yourvocab.net/yourvocab-v1.1/mytoken
> ") or a 303-redirect service; all three proposals are out there and
> have their points. I believe the "hash" variety is simpler to
> understand and configure (for small vocabularies, and we all agree
> we want many small vocabularies rather than a few gigantic ones).
> If the congnicenti think that all the GET requests for
> distinguishing between contents are far enough along, then the
> "slash" variety may make it easier to query individual entries (e.g.
> HTML docs rather than RDF), something which appears to be harder
> using "hash". The point is to make a single mechanism standard - at
> least at first, when there are enough other things to worry about.
> When the semantic web finally chooses a standard, we can still adopt
> it then (if we haven't already).

This is a rather subtle issue, and I agree, something like what you've said. I presume you've seen papers like

@misc{sauermann07,

	Author = {Leo Sauermann and Richard Cyganiak and Max V\"olkel},
	Title = {Cool {URIs} for the Semantic Web},
	Url = {http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/tm-07-01.pdf 
},
	Year = {2007}}

and

@misc{booth07,

	Author = {David Booth},
	Howpublished = {Web page},
	Title = {{URI} Declaration Versus Use},
	Url = {http://dbooth.org/2007/uri-decl/},
	Year = {2007}}

and the httprange-14 resolution. I think this is, like the first, mostly a fine-tuning distribution issue.

> - Looked at a few parsers (e.g. HP's Jena for Java) but still can't
> judge whether there are enough flexible parsers out there to be able
> to say it doesn't matter whether a publisher uses XML, N3 or Turtle
> (I think we can agree we're not going to accept plain ascii, given
> that only a trivial vocabulary - list of words - is interpretable
> and it is trivial to put plain ascii content into any of the
> official formats). We need to make some statement about format,
> even if the statement is that any of the most common formats is OK.
> If we need to choose just one, I still say XML is best, since it
> doesn't need any additional parser at all to get started.

One can't be definitive here, but the list at <http://planetrdf.com/guide/#sec-tools  > includes a fair number of RDF APIs buried amongst other applications. The best known parsers are Jena and Sesame, both in Java, and librdf.org, which is written in C but which has bindings in a variety of scripting languages. I think there are `enough' parsers.

The problem with RDF serialised in XML (aka RDF/XML) remains that, although it is _lexically_ XML, one can't rely on being able to process it sensibly using just XML tools. Thus you _do_ need an RDF parser to get started. It's possible to hand-write RDF/XML which looks like `normal' XML, but that's as far as one can go.

So I still believe (as I know you know; I'm just repeating it here for the list!) that our best tactic would be to require RDF in any format, perhaps with an expectation that a published vocabulary would be available in more than one of the legal formats.

> - given that SKOS mappings appear to be a moving target, it looks
> like there's no point in mentioning anything about what we're
> actually going to DO with the vocabularies. I was hoping we could
> at least support a few RDF containers like rdf:Bag, but it appears
> we're going to depend upon simple things like
>
> <param name="event-is-not" rdf:resource="voe:GRB">

Regrettably yes, the SKOS mappings work does seem to be in flux right now (for those who're not following the relevant list slavishly, the current situation seems to be that although the SKOS Core document seemed almost finished apart from fine details, there now appears to be an expectation that the still changing SKOS Mappings standard will move from its own document into the SKOS Core document). The SKOS Core structures which aren't involved in inter-vocabulary mappings do appear to be stable, though. Alasdair has been keeping track of this and will surely comment if I'm misrepresenting the SKOS list.

It's still an open question how one best describes `the intersection of concept A and concept B' in SKOS -- somewhat unexpectedly it appears to be tied up with the mapping discussion -- but I think it's getting there.

I think we can and should describe use-cases in the IVOA document.

All the best,

Norman

-- 
Norman Gray  :  http://nxg.me.uk
eurovotech.org  :  University of Leicester