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

next