Use profile URL as unique ID for node

[geoffturk]

• instead of just the base URL of the node's website (suggested by Nick)

[geoffturk]

Advantages

• Organizations that have significantly different functions can create profiles customized specifically to those individual functions and store those profiles separately
• A node can host profiles for other entities who do not have their own website to host their profiles themselves (e.g., an organization can offer to host profiles for its members/staff)
• The profileUrl can be obfuscated and/or changed to avoid data being scrapped by aggregators who do not have access to the index

Disadvantages

• The primary URL of an organization is no longer the unique identifier, though it can still be referenced as such using the url field and then aggregators can see if the primary URL (url) and profileUrl contain the same root domain, thus giving weight to the fact that the primary URL is definitively linked to the organization described in the profileUrl

[olisb]

Possible disadvantage (although I guess this applies in other circumstances too and is hence not just related to using the profile URL as the unique ID) is abuse: A bad actor could create a fake profile and host this somewhere... whereas, if the profileurl had to contain the entity's URL, or a recognised (authorised?) hosts URL, we would be able to identify fake profiles.

[geoffturk]

@olisb See my comment about checking that the root domain is the same between the profileUrl and the url (primary URL of the organization) to determine if there is potential spoofing.

Overall the advantages are pretty significant so we will go forward with using the hash of the profileUrl (the nodeId) as the unique identifier of a node in the index.