next

[Frederic V. Hessman]

While you have been digesting the latest proposal, I've been perusing  
various things and suggest we address the following as well:

- 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".

- 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).

- 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.

- 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">

(for a VOEvent-ish artificial example) for a while.

Rick