We've currently a debate here about original domain names versus generic domain names in term of seo efficiency.
We mean by generic domain names, domains like :
- buy-hifi.com
- game-news.com
- easy-meet.com
We mean by original domain names, domains like :
- hifihot.com
- gamesmaniac.com
- lovein.com
What is your opinion ? (actually it's more a poll than a actual question but developments are welcome)
I remember reading an article about AccuWeather being offered the chance to buy weather.com. They passed on it because it didn't reflect their image, The Weather Channel snatched it afterwards, and AccuWeather ended up regretting their decision. While a generic name won't sing your brand, and a brand is important, it's hard to say which is better. I couldn't imagine generic domain names for companies like Apple, Microsoft, IBM, etc., so I suppose it depends. What a lousy answer. How about this: both. Why not have both name types and offer redirection?
Related
Sorry if this question sounds weird but I would like to learn about this more and searching this on google gives me results about other keywords after coming to the word about. I think that's how Google is designed to work, so it gives me no information about https://about.
What is this domain about.*? Examples:
https://about.me
https://about.google
I understand that I can have about.mydomain.com but how come the above 2 domains do not have any extension at the end?
Is it possible for a normal user like us to have https://about.myname? i.e. https://about.kelsey?
TLDs are set up by ICANN, which, after approval, designates a registry that can assign domains under that TLD. So if you're influential enough to get ICANN to approve .kelsey, you're good to go; Google managed to do exactly that, hence the about.google URL. In many other cases, people use TLDs that have been assigned for a particular country as if they were generic (i.e., non-country-based) TLDs simply because they coincidentally look like one. .me, for instance, is the country TLD for the European country of Montenegro, it was originally not designed to have anything to do with the English pronoun "me". Similarly, TV stations like to use the TLD .tv, which was assigned to the Pacific island nation of Tuvalu. And that country specifically markets its domain names to TV stations.
I have read that some of the first TLD where registered back in 90s, including .cz, .pl and other. So domain .SU was. That was domains for national needs.
But who have rights to become a maintainer of national domain? How that procedure looks like?
I also read that .SU TLD was proposed by Finnish student. But how can a student register national domain that supposed represent country?
I couldn't find information about that on Google.
You can find all data on the IANA webpage at https://www.iana.org/domains/root/db or just query it with whois.
.CZ is listed as created on 1993-01-12 and .PL on 1990-07-30
You can go back with some in 1985 like .UK or .US.
.SU had a complicated life because, as a ccTLD it should not exist anymore as the country it represented does not exist anymore. However for non technical reason, it subsists. You can find some discussions there : https://www.icann.org/news/announcement-2-2006-12-05-en
But who have rights to become a maintainer of national domain?
This is a complicated question, and not a technical one nor a programming one.
In short, IANA uses the ISO list on country codes (with some exceptions, like .UK and .EU) and takes input from the relevant government. Now the problem is that some countries are not stable, and also change. So there are a lot of complicated cases. Some ccTLDs are also marketed as non ccTLDs (like .CO or .TV) because the government decided to give its management to some external companies, for some financial agreement.
"Mistakes" happen also, see for example https://medium.com/#Oskar456/stolen-sk-domain-717e070f6735
You can find more about the IANA process at https://www.iana.org/help/cctld-delegation
Each IANA decision to delegate a ccTLD to a country is associated with a "IANA report" listing the justifications. You can read them for whatever country you wish at https://www.iana.org/reports, like a recent one for .TD for example at https://www.iana.org/reports/2018/td-report-20180227.html
The core business is codified, before ICANN even existed in https://www.rfc-editor.org/rfc/rfc1591
IANA adheres to that, and you can find further documentation at https://www.iana.org/domains/root/help
For more details in general, I would recommend you to read my extensive reply to a related question about TLDs and wars: https://superuser.com/questions/1332236/what-happens-to-country-specific-tlds-in-a-war-involving-that-country/1332238#1332238
In Salesforce's Service Cloud one can enable the out of the box search function where the user enters a term and the system searches all parts of the database for a match. I would like to enable smart searching of acronyms so that if I spell an organizations name the search functionality will also search for associated acronyms in the database. For example, if I search type in American Automobile Association, I would also get results that contain both "American Automobile Association" and "AAA".
I imagine such a script would involve declaring that if the term being searched contains one or more spaces or periods, take the first letter of the first word and concatenate it with the letters that follow subsequent spaces or periods.
I have unsuccessfully tried to find scripts for this or articles on enabling this functionality in Salesforce. Any guidance would be appreciated.
Interesting question! I don't think there's a straightforward answer but as it's standard search functionality, not 100% programming related - you might want to cross-post it to salesforce.stackexchange.com
Let's start with searchable fields list: https://help.salesforce.com/articleView?id=search_fields_business_accounts.htm&type=0
In Setup there's standard functionality for Synonyms, quite easy to use. It's not a silver bullet though, applies only to certain objects like Knowledge Base (if you use it). Still - it claims to work on Cases too so if there's "AAA" in Case description it should still be good enough?
You could also check out the trick with marking a text field as indexed and/or external ID and adding there all your variations / acronyms: https://success.salesforce.com/ideaView?id=08730000000H6m2 This is more work, to prepare / sanitize your data upfront but it's not a bad idea.
Similar idea would be to use Tags although that could explode in size very quickly. It's ridiculous to create a tag for every single company.
You can do some really smart things in data deduplication rules. Too much to write it all here, check out the trailhead: https://trailhead.salesforce.com/en/modules/sales_admin_duplicate_management/units/sales_admin_duplicate_management_unit_2 No idea if it impacts search though.
If you suffer from bad address data there are State & Country picklists, no more mess with CA / California / SoCal... https://resources.docs.salesforce.com/204/latest/en-us/sfdc/pdf/state_country_picklists_impl_guide.pdf Might not help with Name problem...
Data.com cleanup might help. Paid service I think, no idea if it affects search too. But if enabling it can bring these common abbreviations into your org - might be better than reinventing the wheel.
As mention in title, I would like to know if the top level domain can be exactly 2 character and it is not country code.
Technically? Of course. Are there any? Well, if you're picky there's at least one that used to be a country code but no longer is (.SU). Will you ever be able to register a top-level domain that is not a country code? Almost certainly not.
I have a website which hosts web documents & web applications and also acts as an origin server for documents and applications that are served to a client via a proxy web site.
I'm finding it quite difficult to find the correct names to model the players in the http request in my server-side application.
For example, Hypertext Transfer Protocol (RFC 2616) describes the parts of an HTTP URL as:
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Whereas RFC 1738 uses this terminology to define the parts of an URL:
An HTTP URL takes the form:
http://<host>:<port>/<path>?<searchpart>
Lets say I want show an advert next to some primary content on a web page that is hosted on my origin server.
I would want to tell the complementary content server to find the best advert to suit the primary content and render them both together as the resource which is served up at an URL.
One of my biggest problems finding the correct words to differentiate between:
the client-facing-URL (the web address that someone might type into the browser bar - ie. http://example.com/mydocument?page=2) (I am calling this the canonical URL at the moment)
the origin-server-URL (the address that the gateway server calls upon to get the page i.e. http://originserver.example.co.uk/version2/mydocument?page=2)
the actual content at the canonical URL (which is always changing)
the revision of that piece of actual content at that URL
the name of the thing that defines the link between the URL and the current content (the semantic placeholder / or praps the semantic specification) - i.e. http://example.com/mydocument means ''a list of books relating to hockey''
page 2 of the content at the canonical URL
page 2 of the content shown by the application after a filter has been applied
etc, etc
I have heard that there are books written to define domain specific languages for various industries.
and there are books like Fowler's Analysis Patterns: Reusable Object Models (which i have not read).
So my question is :
Are there any books/website/published models that summarise all the w3c specs, best practice, SEO termininology and wrap it all up into nice 'n' handy a published object model that can be a truly ubiquitous language for web applications that I can adopt for my web app?
Basically something to cut the ambiguity.
links:
RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt)
HTTP/1.1 RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2)
Unless there's something I'm not seeing in my jet lagged state, I think both definitions you cite actually are the same thing expressed using a different notation. This first is much clearer as it is specific as to which parts are required and which are [optional].
From what I understand of your question, as far as URI's/URL's are concerned, everything past the hostname/port number only has to be syntactically correct. I think you're asking what is semantically correct and the answer unfortunately boils down to "anything goes as long as the syntax is right". When dealing with third party sites, you really have to take what they are giving you unless you have influence with them. For your own site, you may want to look into how URLs are formatted by folks using REST (as a suggestion, others, please chime in on that).
The web has been a wild-wild-west cowboy land for so long that no matter what the specs are, unless it flat out produces an error, you often need to tolerate a lot of loose-ness in terms of semantics. This is just one reason why some folks talk about the dream land of the "semantic web".
Considering that the web protocols are extensible, no complete language is possible.