Format of tokens

[Brian Thomas]

Hi All,

Just to preface this email...I'm not trolling or trying to start a 
flame war here. Simply stating a *mild* preference, with some
late-night justification. I suppose I should have left the later 
out as there was simply a call for a vote, not an argument.

On Friday 02 November 2007 12:45:30 am Rob Seaman wrote:
> On Nov 1, 2007, at 8:58 PM, Brian Thomas wrote:
> 
> > you really can't go part way, either something is human- 
> > recognizable, or it isn't.
> 
> By this standard, the underscores are unnecessary for it to be human- 
> recognizable.

I think that is a matter of opinion (and really not terribly fruitfull
for argument as it can't be "proven" one way or the other). 
In actuality, I'm quite happy to see the id's be completely unreadable. 
But I figure if we are going to give a sop to having some readability, 
then spaces would be nice (but not critical). 
AfterallitsquitedifficulttoparseasentencewithoutthemandIthinkthesameistrueoftheids.

> 
> > If con_science is not to be confused with conscience then I suppose
> > the author of the node can invent some convention to suit their  
> > needs, but
> > its likely to take up more characters (like 'conunderscorescience').
> 
> Unless we're worried about penology, 
 
Creating standards is something akin to it. As there are laws to proscribe 
incorrect action, so there are standards which forbid incorrect formatting!

> do any significant astronomical   
> examples spring to mind?  Do the few examples requiring  
> disambiguation justify adding underscores to virtually all tokens?

Well, not at the moment. I think underscores as something nice to have, not a
necessity. As I wrote above, my favored option is not on the table: make the id's
completely obscure.
	
> 
> > Is there really a parser out there which can't handle an  
> > underscore? Or is
> > it that people are worried that if we allow this one non-alphanumeric
> > character more will follow?
> 
> How about dots and semicolons?  With #con;science we can have our  
> UCDs and parse them, too.

No idea, but I think you are implying "slippery slope" here.

> 
> > So...unless I hear dire predictions of "slippery slope, slippery  
> > slope" or
> > how any RDF parser can't handle underscores in names I'm mildly in
> > favor of the underscore.
> 
> "Better is the enemy of good enough" describes the slipperiest of  
> slopes.
>

Look, in the end, as I wrote before, the main issue is parsability of name's. The 
rest is, IMO, stylistic sugar, and so, is a matter of opinion on what is best. 
If the creators of RDF/SKOS didnt see fit to enforce non-readable or barely-readable 
names, then I am hesitant to do so myself. 

> Alasdair wrote:
>
> > So..it would seem that the strongest reason is a). Point b) is really a stylistic
> > one (but it seems to require that we always provide rdf:label when this
> > style of naming concepts is in effect).
>   
>  Again, this is not quite correct. It does not require every concept to have an rdf:label but 
>  it does require every concept to have a preferred label. However, as I said above, it does 
>  not make sense to have a concept without a preferred label.  
 
Sure, but doesn't the standard already enforce that? I'm not sure that having barely readable
id's adds anything in this regard, so it doesnt seem a strong justification for them. Rather, it
would simply be better to not tempt the user _at all_ to use the name for anything other than
a unique id, so, again, I really  favor generating obfusticated/obscure values.

As Ed and I are apparently out-voted anyway, I'm not sure what further discussion will add.
And, at any rate, considering the gravity of this issue, I am happy to let it go in favor of starting
my weekend early :)

Cheers!

=brian

ps. Don't forget! Today is the last day to submit those ADASS papers!!


> - Rob
> 
>