Except a URL only points to one resource. The idea here is that this identifier would exist on any resource related to PEP (maybe even in URLs).

>Except a URL only points to one resource

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)

That’s not a problem, you just add a meta or a link tag that points to “the” url for your project (maybe og:app-id Or a link with rel=“app”)

Yeah but urls and names might need to change due to marketing. A hash would uniquely id the project and let the marketing aspect be dynamic.

Although if the actual project name, authors, and codebase changes is it even still the same project?

There's a number of professions I'd like to add to that pyre please. ;)

tzs is proposing URNs rather than textual program names. A URL is unnecessarily specific (though I suppose you could anycast URL resolution)

> RFC 4122 defines a Uniform Resource Name (URN) namespace for UUIDs. A UUID presented as a URN appears as follows:[1]

> > 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 &lt; CreativeWork &lt; 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 &lt; CreativeWork &lt; Thing"/>
      <meta itemprop="name" content="a rose by any other name" lang="en"/>
    </div>
  </div>

More in line with using "golang" since it is far easier to search for than just "go"