[At-Large] Opera now lets you ditch boring web links and use emojis instead
Karl Auerbach
karl at cavebear.com
Mon Feb 21 18:37:03 UTC 2022
You are quite right about the constrictions of predefined taxonomy of
attributes such as Dublin Core. I suggested it merely to get people
thinking about lookups by attribute rather than by name. My sense is
that we need something that allows growth via use, much like the hash
tagging that we see in so many places. There will, of course be
conflicts and collisions.
But if we look at the most successful of all resource-binding systems,
the biological systems of living entities to find food and mates, we see
a lot of collisions and conflicts. We see butterflies and moths
adopting color patterns as signals for the attribute of "species" (for
mate finding) and also as a defense "my color pattern makes me look like
another species that tastes bad, so don't eat me even though I am of a
good tasting species".
(In something as large, diverse, and changing as the internet we may
have a lot to learn from the biological world.)
Attribute systems are usually just a preliminary culling to find
potential targets of interest.
My example of wanting to buy some M-4 screws and looking up via
attributes "hardware store" and "near me" could lead to results that are
closed or deal only in wholesale sales. So I'd have to do some
additional refinement of the search results. (This is true in
biological systems as well.)
Lookups by attribute create an interesting, and often quite valuable,
side effect often called "serendipity" - that happens when you are
looking for things of type X and you come across something close to X
that turns out to be useful. This occurs in libraries as one wanders
the stacks looking for a particular volume (perhaps to discover that
some professor checked it out 20 years ago and never returned it, grrrr)
and you stumble across something else of interest. DNS doesn't have
serendipity. DNS is a good system for use underneath attribute systems.
--karl--
On 2/21/22 8:13 AM, sivasubramanian muthusamy wrote:
> The attributes concept of the Dublin Core model could be applied in
> public interest to enrich the way Domain names are chosen /
> registered, especially in the case of highly valuable/useful generic
> names. The cataloguing model alone wouldn't suffice, because the
> library-class metadata coding by all segments of users (even business)
> would not happen so methodically as in the libraries, leaving
> autotagging by machine learning as the predominant method by which the
> catalogues would be compiled. ( comment based on a quick, rapid look
> for the first time on Dublin Core documentation, it is possible that I
> might have missed something very basic)
>
> Sivasubramanian M
>
>
>
> On Mon, Feb 21, 2022 at 8:40 PM Carlton Samuels via At-Large
> <at-large at atlarge-lists.icann.org> wrote:
>
> Thank you Karl for prompting organic thinking every time you
> intervene in these discussions. As an AT&T alumnus and having sat
> through a year of training ( a week every month) at Bell Labs, the
> fellas were keen to teach us some of those lessons
> you reprised in commentary.
>
> Karl wrote.........
>
> /"...I also am of the belief that on the net attributes are often
> more important than names. For instance, if I am looking to buy
> some machine
> /
> /screws I care more about the attribute "hardware store" than
> anyparticular name of such a store. In that vein I sense that it
> might be
> a useful endeavor to create a list of attribute types [and for
> each somedefinition of the possible values]. I'm thinking
> something like the
> Dublin Core metadata definitions, but of more universal
> applicability.To make use of such a world in which things are
> known by their
> attributes as much as by their names we would need new protocol
> andserver machinery to do the kind of soft lookups that attribute
> systems
> need. As is my tendency, I sense that such things might well
> learn fromthe biological world in which "adequate matching" is
> often a key to
> survival."/
>
> By gum! I taught in the library school at the UWI for years Karl,
> specifically digital libraries and associated concepts of
> cataloguing and searching where the Dublin Core is central to
> defining a metadata element set that is inclusive of coding
> special collections.
> I share your views on the relative importance of attributes vs.
> names for information gathering. And have encouraged a kind of
> extension to the Dublin Core orthodoxy in service.
>
> To the larger point you make on accommodating innovation from the
> edge, one of my friends, Evan Leibovitch, has been arguing for years
> that a reckoning is coming and will come to the DNS by several
> usurpations, among them implementations based on attribute systems.
> History will absolve him, I think.
>
> Carlton
>
>
>
> ==============================
> /Carlton A Samuels/
> /Mobile: 876-818-1799
> Strategy, Process, Governance, Assessment & Turnaround/
> =============================
>
>
> On Sun, 20 Feb 2022 at 23:36, Karl Auerbach via At-Large
> <at-large at atlarge-lists.icann.org> wrote:
>
> As a personal issue I think the notion of emojis in DNS is
> little more
> than a concession to a (hopefully) passing childish fad.
>
> And from a security perspective (not to mention the confusion
> of users
> in genera) I have a intuitive sense that it is a fad that
> contains seeds
> of trouble.
>
> But I'm just one person out of billions of us. I don't use
> emojis, but
> it seems that a lot of us do.
>
> And I don't want to be like the voice of Ma Bell in the 1960's
> loudly
> proclaiming that packet switching and the attachment of
> foreign devices
> were something to be avoided and banned.
>
> So how do I decide?
>
> So using the rubric of my "first law of the internet" I start
> with the
> position of "emojis ought to be allowed" on the basis of them
> being of
> private benefit (although I personally find it hard to see
> that benefit
> or credit it with value.)
>
> Then I say "but is there a public detriment and if so is it
> substantial
> enough to block that private benefit?"
>
> As things stand right now I can't clearly and concretely
> articulate the
> public detriments (although I feel that they are out there)
> much less
> measure them.
>
> Which, according to my rule means that I would conclude to
> take no
> action (at this time) against emojis in domain names. But I'd
> suggest
> inquiries and research to obtain more concrete information
> about the
> issue. (Yes, I realize that my conclusion contains a strong
> possibility
> that we could end up with an deeply entrenched ill practice.)
>
> Part of this is informed by my belief that the domain name
> system is
> slowly fading from the public eye; that we are moving into a
> world in
> which DNS names are becoming more a part of the hidden
> machinery of the
> net (like MAC addresses) and that higher level naming
> abstractions,
> things like Twitter names or Facebook handles, are becoming
> the more
> prevalent forms of naming on the net.
>
> I also am of the belief that on the net attributes are often more
> important than names. For instance, if I am looking to buy
> some machine
> screws I care more about the attribute "hardware store" than any
> particular name of such a store. In that vein I sense that it
> might be
> a useful endeavor to create a list of attribute types [and for
> each some
> definition of the possible values]. I'm thinking something
> like the
> Dublin Core metadata definitions, but of more universal
> applicability.
> To make use of such a world in which things are known by their
> attributes as much as by their names we would need new
> protocol and
> server machinery to do the kind of soft lookups that attribute
> systems
> need. As is my tendency, I sense that such things might well
> learn from
> the biological world in which "adequate matching" is often a
> key to
> survival.
>
> --karl--
>
>
> On 2/20/22 17:29, Alejandro Pisanty wrote:
> > Karl,
> >
> > TL;DR, QED for no emojis in DNS. Thanks.
> >
> > Alejandro Pisanty
> >
> > On Sun, Feb 20, 2022 at 3:52 PM Karl Auerbach via At-Large
> > <at-large at atlarge-lists.icann.org
> > <mailto:at-large at atlarge-lists.icann.org>> wrote:
> >
> > On 2/20/22 8:52 AM, sivasubramanian muthusamy via
> At-Large wrote:
> >
> > > What does ICANN think about private and often proprietary
> > > 'innovations' that aspire to "cause a major shift in
> the way the
> > > Internet [DNS] works" ?
> > >
> > Remember, the Internet came from a rejection of the
> status-quo, the
> > world of circuit switching and central control.
> >
> > The question you asked is not far distant from a
> question whether we
> > ought to nail down the Internet in the same way the
> telcos of the first
> > three quarters of the 20th century ossified the
> telephone networks.
> >
> > Ma Bell and other telco's imposed extreme, and often
> arbitrary, limits
> > on innovation at the edges. Take a look at the 1956 US
> case regarding
> > the Hush-a-Phone. (In that case AT&T tried to block the
> attachment of
> > what was essentially a plastic hand that would be
> attached by the user
> > to the mouthpiece of a telephone. At&T made wild claims
> that that would
> > cause the telephone network to collapse and repairmen
> would blown off
> > the top of telephone poles.) Then look at the
> Carterphone and MCI
> > cases.
> >
> > One of the hallmarks of the Internet is permissionless
> innovation at
> > the
> > edges. Clearly there are balances to be made, but we
> risk a balance
> > that
> > pushes too much control to the center.
> >
> > Some decades ago I distilled this balance into a short
> formulation:
> >
> > First Law of the Internet
> >
> > + Every person shall be free to use the Internet in any way
> > that is privately beneficial without being publicly
> > detrimental.
> >
> > - The burden of demonstrating public detriment shall
> > be on those who wish to prevent the private use.
> >
> > - Such a demonstration shall require clear and
> > convincing evidence of public detriment.
> >
> > - The public detriment must be of such degree and
> extent
> > as to justify the suppression of the private
> activity.
> >
> > https://www.cavebear.com/old_cbblog/000059.html
> > <https://www.cavebear.com/old_cbblog/000059.html>
> >
> > --karl--
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20220221/549ba8c2/attachment-0001.html>
More information about the At-Large
mailing list