ImageMonkey
component labels naming convention?
I am currently working on unlocking more component labels. Currently, all existing component labels are formatted the following way: <base label>.<xy>='<component'>. To give some concrete examples: dog.has='mouth' or cat.has='eye'.
The question is now, do we want to keep it that way or do we want a different syntax? I've seen, that a lot of trending labels have the syntax: <component>/<base label> (e.q: hand/person). I totally get, that the slash notation is easier to type...so it's perfectly fine to use those for trending labels :) Up to now, I've always renamed the slash notation to the "official" syntax. i.e: hand/person would become person.has='hand'.
Should we keep the "official" syntax that way or should we go for the slash notation? For me both is fine...renaming labels is really easy...so it's not an extra effort.
In my opinion the slash notation is easier, while the dot notation might be more expressive. Instead of .has we could use other .xy expressions. e.q: car.brand='peugot' or dog.size='medium'. If we go for the slash syntax, those will become peugot/car and medium/dog.
Personally, I am a bit in favor of the dot notation...it's harder to type, but I think it's more expressive in the long run. (I think with the slash notation we might end up with ambiguity in case the label expressions get more complex) But it's really not a strong preference..so in case we want the slash notation it's also perfectly fine to me.
edit: In case we go for the slash notation, we probably need to find a different syntax for label blending. If I remember correctly, we talked about using the slash operator for label blending?
hmm.. lots to balance.
the slash has many potential meanings, but is easy to remember and type, and thats how you started out (eg head/dog).
If I remember correctly, we talked about using the slash operator for label blending?
Yes.. it would be very intuitive to be able to mix grass/soil, sand/grass and so on
my first guess (from a programmers mindset) would have been dog.head i.e. like object components , but you have a general property system (states like posture, gender , materials etc) which is why I guess you're saying dog.has=head (and car.brand=... person.gender=male, person.posture=sitting wall.material=bricketc..)
There's also the C++ namespace operator, dog::head .. but again possibly very obscure for casual users
Would it be enough to distinguish what the slash means based on specific labels, i.e. "if it's a A part name/B non part , then you interpret it as B.has=A" .. but are there any ambiguities?
Parts I can think of (animals/people/vehicles/buildings)-before the slash: head foot paw hand tail wing wheel wing mirror headlight intake door window handle blade lid ...
objects that have parts (i.e. put after the slash) car person dog animal cat man woman aircraft truck house skyscraper ...
are there any examples that would break this assumption?
(it might also be possible to make certain labels material modifiers brick/* metal/*.. but glass is the pathological case, unless we say 'glass/cup', disallow glass on it's own- prefer to interpret as a material)
the slash has many potential meanings, but is easy to remember and type,
yeah, totally agreed. The "easy to remember and type" is definitely a huge plus.
Would it be enough to distinguish what the slash means based on specific labels, i.e. "if it's a A part name/B non part , then you interpret it as B.has=A" .. but are there any ambiguities?
Yeah, also thought about that. I guess we could add a client side setting, that let's you specify whether you want to tuse the / as parts separator. Similar to the label separator that one can specify in the annotation settings. In case you've selected that you want to use / as a parts separator, it will be interpreted as B.has=A. That all happens client side...i.e when the label will be sent to the server, it will already be in the right (B.has=A) format. Would that solve the problem?
Does it make sense to use a different operator for label blending then? I am a bit worried that we run into a few cases where we accidentially interpret the / the wrong way (e.q: we interpret it as label blending although it should be a parts separator). If we choose two completely different operators, I guess we could minimize the risk a bit.
I think this might also be easier to explain to new users. "Use notation x if you want to specify a component and use notation y for label blending". Just thinking what would be a good separator for label blending? ~, +...?
If we choose two completely different operators, I guess we could minimize the risk a bit.
Just thinking what would be a good separator for label blending? ~, +...?
I was thinking foo|bar (like 'OR') could handle mixing.. I must admit '/' is the most intuitive as it tends to be used that way in natural language. eg https://www.englishclub.com/writing/punctuation-slash.htm .
+ could make sense too
perhaps if the user types foo/bar, the UI could ask what is specifically meant and replace it with whatever un-ambiguous syntax is chosen
(maybe even a single colon for parts? dog:head car:wheel ?)
do parts deserve a special syntax? (when there's posture, material, gender aswell)
do parts deserve a special syntax?
in my opinion parts should be treated exactly the same as all other properties (gender, material...). What I am hoping is, that we eventually come up with a consistent naming schema that works for all labels. That can either be something like car::brand::peugot, dog::has::head, or car.brand=peugot, dog.has=head or something completely different.
Personally, I would prefer, if we find a naming convention, that starts with the base label (i.e: dog:: resp. dog.), mainly because one only needs to type dog and then the autocompletion will show a list of all dog* labels.
On top of our naming convention, we could define shortcuts (e.q: a single colon can be a shortcut for parts). But I would see those things only as shortcuts (for advanced users). I think for the occasional user those shortcuts are more complicated than helpful. Those users are probably better off sticking to the official naming conventions, although that might require more typing.
I guess it might be the case that selecting part,mateiral,brand etc in the UI helps find the specific labels . besides that, if starting with text entry, perhaps if you type 'glass' it can then suggest disambiguation (cup or material), whilst the less ambiguous words would get there directly (a wheel is always a wheel)