If you search for PEP now you'll find python enhancement proposals, and the "Philippine Entertainment Portal" and the stock code for PepsiCo.
If you search for PEP now you'll find python enhancement proposals, and the "Philippine Entertainment Portal" and the stock code for PepsiCo.
That way once I know that say PEP the PDF editor exists and find its 128-bit number (let's say that is 379dd864b16eaca3ce94c15a6bdfcc73), at least I can subsequently toss a +379dd864b16eaca3ce94c15a6bdfcc73 on my searches to effectively let the search engine know I want PEP the PDF editor results rather than PEP the python enhancement results or PEP the entertainment portal results or PEP that refreshing beverage company stock symbol.
"xxd -l 16 -p /dev/urandom" is a handy way to get a 128-bit random hex number. A UUID generator works, too, although they usually include some punctuation you will need to delete and you might have to lower case their output.
We already have something similar: URLs.
isn't that exactly what this is asking for though? A URL can by definition only point to one resource. So if you include that URL with every other reference to the project (in the app descriptions, blog posts about it, etc) then you always know you're talking about the same thing. It makes a lot more sense that any resource related to this PDF editor should include a link to "https://macpep.org" instead of including some random 128 character string. Any resource related to python peps should include a link to "https://www.python.org/dev/peps/" (which all PEPs do, by virtue of having a url that's a subdirectory of the PEP index URL)
Although if the actual project name, authors, and codebase changes is it even still the same project?
> > urn:uuid:123e4567-e89b-12d3-a456-426655440000
https://en.wikipedia.org/wiki/Universally_unique_identifier#...
Version 4 UUIDs have 122 random bits (out of 128 bits total).
In Python:
>>> import uuid
>>> _id = uuid.uuid4()
>>> _id.urn
'urn:uuid:4c466878-a81b-4f22-a112-c704655fa4ee'
Whether search engines will consider a URL or a URN or a random str without dashes to be one searchable-for token is pretty ironic in terms of extracting relations between resources in a Linked Data hypergraph. >>> _id.hex
'4c466878a81b4f22a112c704655fa4ee'
The relation between a resource and a Thing with a URI/URN/URL can be expressed with https://schema.org/about . In JSON-LD ("JSONLD"): {"@context": "https://schema.org",
"@type": "WebPage",
"about": {
"@type": "SoftwareApplication",
"identifier": "urn:uuid:4c466878-a81b-4f22-a112-c704655fa4ee",
"url": ["", ""],
"name": [
"a schema.org/SoftwareApplication < CreativeWork < Thing",
{"@value": "a rose by any other name",
"@language": "en"}]}}
Or with RDFa: <body vocab="https://schema.org/" typeof="WebPage">
<div property="about" typeof="SoftwareApplication">
<meta property="identifier" content="urn:uuid:4c466878-a81b-4f22-a112-c704655fa4ee"/>
<a property="url" href=""></a>
<a property="url" href=""></a>
<span property="name">a schema.org/SoftwareApplication < CreativeWork < Thing</span>
<span property="name" lang="en">a rose by any other name</span>
</div>
</body>
Or with Microdata: <div itemtype="https://schema.org/WebPage" itemscope>
<link itemprop="http://www.w3.org/ns/rdfa#usesVocabulary" href="https://schema.org/" />
<div itemprop="about" itemtype="https://schema.org/SoftwareApplication" itemscope>
<a itemprop="url" href=""></a>
<a itemprop="url" href=""></a>
<meta itemprop="identifier" content="urn:uuid:4c466878-a81b-4f22-a112-c704655fa4ee" />
<meta itemprop="name" content="a schema.org/SoftwareApplication < CreativeWork < Thing"/>
<meta itemprop="name" content="a rose by any other name" lang="en"/>
</div>
</div>8^256 is a huge number.
8 character ascii not 8 bit.
It's early.
That's 8 bits ^ 8.
Or 256 ^ 8.
and easily able to be represented searching online with 8 characters.
687c066db3458f7cbd5cc8bd58a65c64.
Vs.
*Xrh6x1!
You just have to eliminate dictionary words.
Even though he's friend with Larry Tesler, the man responsible for our modern use of cut and paste
Links should bring back to the original source not point to some random text, with no context, that needs to be indexed
Only issue would be handling inevitable "SEO-ified" abusers of it.
The problem with any SEO mitigation is that the 128 bit string is intended for SEO. If you make a cool new thing then I blog about it I want to use your 128 bit string and you want me to use it too! So how do you prevent someone else from putting it on a linkfarm? I don't think trademark helps there.
Does schema.org etc support ids beyond keywords/categories? I guess the id could just be a keyword.
Maybe a public registry where you claim an id for a topic, similar to claiming a yelp page or an ISBN number. Then anyone posting related content includes that id. Popular topics could be grouped. You could generate memorable ids for most known topics/products/etc, and people just utilize them organically, robots could apply them automatically over time also.
It's especially bad for words with many definitions, like "bridge repair", could mean a dental bridge, guitar bridge, or a bridge over a lake.
Seems like PEP is used for more things too :)
The good news is google is smart, and if you add a couple of subject keywords it pretty much always works.
For example if you search "pep pdf editor" the site shows up in first place.
My only issue is naming things after words that are so incredibly common they're on practically every page anyways, and thus truly useless for searching. I'm looking at you, Go.
It is very obvious if you google "pdf pep" python enhancement proposals or pepsi is not going to show up.
Naming is hard, I have a dream that people would stop complaining about it. There is names/acronyms for literally everything, the chance of you finding something unique is very very small.
Nope. First page is mostly CDC, WHO, etc. Nothing about python or this project.
(Wine is not emulator)
Thank you for understanding. :)
I would say for acronyms containing 2, 3, 4 letters these are all going to be taken at this point.
What matters is how much do the acronyms overlap. Pepsi (food & drink) has nothing to do with PDF editors (tech).
pEp (or p≡p) [1] on Android is a nice K-9 fork with material design and GPG support / opportunistic encryption. Its not very well known though.
Worst would've been if there's a PEP directly related to PDF.