Re: New Specification Published!

On Feb 7, 2013, at 10:59 , Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi,
> 
> Not sure I'm going to deliver crucial input, but in case, here are my two cents.
> 
> - I find shorter namespaces good, and I wouldn't mind using 'oa' even if it means sthg else--first come fist serve, and it matches what other vocabularies at W3C seem to be doing. Worst case, if the group prefers a meaningful label, I'd prefer /annotation/ over /openannotation/. I suppose 'open' does not add much info in the context of a W3C namespace. Such a change would also tell something about the maturity and ambition of the initiative :-)
> 
> - I like 'core', but that because I still would prefer the current namespace to be broken down (especially, the motivation instances could go to their own sub-space).
> If the modules defined in the namespace (like 'annotation/core') do not match the modules in the spec documentation, it may be counter productive. Which makes me realize that we've got a "core of a "core",, which is a bit awkward:
> http://www.openannotation.org/spec/core/core.html
> But I suppose we can make it disappear when the HTML also moves to another place.
> 
> Side question: Ivan, Phil, would it be possible to have a core in http://www.w3.org/ns/openannotation/ and later extensions in say, http://www.w3.org/ns/openannotation/ext/? Or would it ruin your dreams of simple maintenance of the namespace?
> 

Well... this is again the # vs. / question.

Having

http://www.w3.org/ns/annotation/core#BLABLA
http://www.w3.org/ns/annotation/ext1#BLABLA

is of course no problem. Having '/' means a file per term, which means the maintenance costs become higher. Whether that is spread over several directories is of course not a real difference. It will be the number of terms that will count (in contrast to the number of extensions in the case of a '#' approach).

Cheers

Ivan


> 
> Best,
> 
> Antoine
> 
> 
>> Dear Robert,
>> 
>>> Yes, I could buy the argument to lose /core/ now that we don't have
>>> anything in /extensions/ . On the other hand, it's probably good for
>>> the future to have the possibility of /extensions/ if we need it.
>> 
>> And then you will add /misc because everything is miscellaneous? :-) Perhaps those future extensions that do not exist yet will find another umbrella and short name they like. I appreciate you want to foresee the future but sometimes, pragmatics is good too, and in this case, it does not harm extensibility so I would indeed be in favor of dropping /core.
>> 
>>> From the set of namespaces that we use, not including our own the
>>> tally looks like: / has 5, and # has ... 5 :)
>>> Unless there's a W3C best practice that we should follow that we don't
>>> know about?
>> 
>> Yes, there is one, at least voiced, I'm not sure it has been recorded in any document. This comes back to a very long discussion the community had at the time where w3c was publishing the conversion of WordNet in OWL/RDF and the rationale was:
>> - if your vocab is 'small', then use #
>> - if your vocab is 'large', then use /
>> In the case of Wordnet, it is obvious you don't want to load a several mega bytes file each time you have to dereference a synset.
>> I consider OA small enough to adopt the # pattern.
>> Best regards.
>> 
>> Raphaël
>> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf