Currently, our site uses BING spelling check to correct our search.
However, when searching "medical suppliers", BING decides to change it to "medical supplies", which is not the term we uses in our system.
Using just the word - suppliers, BING doesn't change it to suppliers. It seems that BING only changes it in the context of medical suppliers.
Is there any way to tell BING to check the spelling of the word individually, and not worrying about the context?
If you have search experience on your site, you can have experience similar to Bing.com. It says including results for "Medical Supplies" and provides an option to search for "Medical Suppliers" only. Using "spell" mode is correct in this case.
Related
PSD2, The Payment Services Directive of the EU.
Financial institutions in the EU need to be PSD2 compliant, and there's a bunch of vendors claiming PSD2 compliancy. PSD2 is supposed to be a uniform EU-wide standard, and there's a million whitepapers, video blogs, impact estimates, high level overviews, but no technical specification.
Nothing saying really what message needs to be sent where and then happens what. The closest thing I found is this but even there there's no reference, nothing to imply what exact technical spec they followed.
Does anybody know where to get the official PSD2 technical requirements?
EDIT: I tried my luck with the developers of openbanking project
PS I understand that this question is technically a "questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam"
This question must have a unique and precise answer from a single regulator - the EC, this is not an opinionated answers area.
Here is the UK standard.
https://www.openbanking.org.uk
Also there is a linkedin group to connect developers working on PSD2 and Openbanking with banks, regulators and suppliers here.
https://www.linkedin.com/groups/12069802
I got an answer from the "owner" of the OBP project, I'm posting it verbatim:
Regarding the current status, Open Bank Project API develop branch currently supports OBP API specs 1.2.1 through 3.0.0
We also have an ISO20022 connector (PAIN) for initiating payments.
You can read the OBP specs here:
https://apiexplorersandbox.openbankproject.com/
or use the Swagger:
https://apisandbox.openbankproject.com/obp/v1.4.0/resource-docs/v3.0.0/swagger
or Resource Docs (our own format):
https://apisandbox.openbankproject.com/obp/v1.4.0/resource-docs/v3.0.0/obp
(the Swagger / Resource Doc links can also be found at the bottom of the API Explorer)
Regarding PSD2, PSD2 doesn't explain exactly how countries should comply (e.g. it doesn't define URLs etc.). However, it does say in Article 28 point 3: "Account servicing payment service providers shall also ensure that the dedicated interface uses ISO 20022 elements, components or approved message definitions, for financial messaging".
This is why STET (the recent French standard) uses field names like "PmtTpInf", "InstrPrty", "SvcLvl" and "Cd" etc.
In addtion to the OBP standards mentioned above, we aim to support:
An ISO 20022 version of OBP. This will most likely be requested using a different Mime type on the current OBP URLs and will be implemented as an automatic translation of OBP terms to ISO20022 equivelents (where they exist). We'll probably support ISO20022 short field names and also longer type names (which are verbose but are more self describing).
UK Open Banking standard
STET (French)
Other Country standards.
Thus OBP API will be able to surface multiple standards using one OBP instance and backend connector. It will provide easy to use REST APIs (OBP) and less easy to read ISO20022 interfaces for compliance.
Hope that helps.
p.s. here is STET: https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf
If you are looking for a technical standard that is intended to be applicable across all PSD2 countries, you should check out the Berlin Group spec.
The Open Banking spec is somewhat UK specific, it might be sufficient if you only need to support UK market, or you could extend it to support other products/markets (e.g. SEPA payments).
I've been looking for an answer to this question myself, hoping that I'll find a PSD2-compliant JSON-based answer, rather than have to figure out ISO20022.
I found this brilliant article by Starling Bank saying:
As of November 2017, however, the Open Banking Implementation Entity (OBIE) announced amendments to the scope of Open Banking to broaden out the Open Banking solution to include PSD2 items “in order to deliver a fully compliant PSD2 solution” – which can be read in full here and here.
It seems to me that if Open Banking is designed to be PSD2-compliant and it already delivers detailed specs, then the safest bet here is to simply implement Open Banking specs.
I've also found that viable alternatives to this are:
The Berlin Group's NextGenPSD2 specs, published as a YAML file.
The Stet specs, also published as a YAML file.
The text of PSD2 is here: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32018R0389&from=DE
I found this from here: https://raue.com/en/e-commerce-2/new-eu-regulation-for-electronic-payments-and-online-banking/ which has a helpful summary.
PSD2 is the interface requirement, I don't understand why so many of the responses are about Open Banking, which is just about how to use the interface!
The specs rely a lot on JWTs I found this website very useful if it helps anyone - https://openbankingsdk.com
I have in a website a directory of musicians, music groups and institutions (luthiers, concert halls, etc...).
According with the official documentation of schema.org about MusicGroup, I could include also a solo musician.
My questions are:
Should I assign "Person" to solo musicians and "MusicGroup" to music groups?
If I assign "MusicGroup" to solo musicians, his/her thumbnail will be displayed in the Google search list as rich snippet? (I guess if I assign "Person" to solo musicians it will be displayed).
The same as question 2. but with music groups.
The same as question 2. but assigning "Organization" to institutions.
I am very interested in show the thumbnail in the search list, but also to give a logical and correct semantic syntaxis.
As the Schema.org documentation says, a "MusicGroup" can refer to a solo musician, and should be used. It has the benefit that you can have "album" and "track" properties that allow you to define the solo musician's recorded works (which are not present in "Person").
Probably, but that's entirely up to how Google decide to display search results for your site.
As per the answer to (2)
As per the answer to (2)
To expand on my answers to your questions 2,3 and 4:
Google only display thumbnails for search results in a few rare cases. My suspicion (Google's decision-making process is not public) is that thumbnails in search results are more dependent on having a very high-ranking website and therefore - in Google's eyes - a highly trustworthy and reliable source of information, rather than on the particular schema.org "type" you use.
I am wondering how to go about implementing Location Automation Field, as suggested in this article: http://uxmovement.com/forms/new-form-techniques-proven-to-save-time-and-money/
Are there libraries or services that can help me figure out City/State given the zipcode? I know Google has the Geocoder/decoder or Google Places search that could potentially be useful but their Terms of Use mandate that you must use their services in conjunction with displaying the results on their map, which is a weird thing to do when the user is filling out billing info...
Cheers to you for observing TOS. That's good business.
You could use SmartyStreets. LiveAddress API supports city/state and ZIP code lookups. It now has auto-complete as you type an address, too.
I work at SmartyStreets. In fact, we developed the jQuery plugin which does address validation and auto-complete for you. It even supports freeform address fields.
Related question by yours truly, over on UX stack exchange: https://ux.stackexchange.com/questions/22196/combining-all-the-address-fields-into-one
We need to display meta information (e.g, address, name) on our site for various venues like bars, restaurants, and theaters.
Ideally, users would type in the name of a venue, along with zip code, and we present the closest matches.
Which APIs have people used for similar geolocation purposes? What are the pros and cons of each?
Our basic research yielded a few options (listed in title and below). We're curious to hear how others have deployed these APIs and which ones are ultimately in use.
Fwix API: http://developers.fwix.com/
Zumigo
Does Facebook plan on offering a Places API eventually that could accomplish this?
Thanks!
Facebook Places is based on Factual. You can use Factual's API which is pretty good (and still free, I think?)
http://www.factual.com/topic/local
You can also use unauthenticated Foursquare as a straight places database. The data is of uneven quality since it's crowdsourced, but I find it generally good. It's free to a certain API limit, but I think the paid tier is negotiated.
https://developer.foursquare.com/
I briefly looked at Google Places but didn't like it because of all the restrictions on how you have to display results (Google wants their ad revenue).
It's been a long time since this question was asked but a quick update on answers for other people.
This post, right now at least, will not go into great detail about each service but merely lists them:
http://wiki.developer.factual.com/w/page/12298852/start
http://developer.yp.com
http://www.yelp.com/developers/documentation
https://developer.foursquare.com/
http://code.google.com/apis/maps/documentation/places/
http://developers.facebook.com/docs/reference/api/
https://simplegeo.com/docs/api-endpoints/simplegeo-context
http://www.citygridmedia.com/developer/
http://fwix.com/developer_tools
http://localeze.com/
They each have their pros and cons (i.e. Google Places only allows 20 results per query, Foursquare and Facebook Places have semi-unreliable results) which can be explained a bit more in detail, although not entirely, in the following link. http://www.quora.com/What-are-the-pros-and-cons-of-each-Places-API
For my own project I ended up deciding to go with Factual's API since there are no restrictions on what you do with the data (one of the only ToS' that I've read in its entirety). Factual has a pretty reliable API, which as a user of the API you may update, modify, or flag rows of the data. Facebook Places bases their data on Factual's, just another fact to shed some perspective.
Hope I can be of help to any future searchers.
This is not a complete answer, because I havn't compared the given geolocation API, but there is also the Google Places API, which solves a similiar problem like the other APIs.
One thing about SimpleGeo: The Location API of SimpleGeo supports mainly US (and Canada?) based locations. The last time I checked, my home country Germany doesn't has many known locations.
Comparison between places data APIs is tough to keep up to date, with the fast past of the space, and with acquisitions like SimpleGeo and HyperPublic changing the landscape quickly.
So I'll just throw in CityGrids perspective as of February 2012. CityGrid provides 18M US places, allowing up to 10M requests per month for developers (publishers) at no charge.
You can search using a wide range of "what" and "where" (Cities, Neighborhoods, Zip Codes, Metro Areas, Addresses, Intersections) searches including latlong. We have rich data for each place including images, videos, reviews, offers, etc.
CityGrid also has a developer revenue sharing program where we'll pay you to display some places as well as large mobile and web advertising network.
You can also query Places via the CityGrid API using Factual, Foursquare and other places providers places and venue IDs. We aggregate data from several places data providers through our system.
Website: http://developer.citygridmedia.com/
I am using Scantron Cognition Enterprise at work to capture data from scanned forms. Building these forms is tedious at best, especially when it would be nice to have a library of pre-built objects to use. Unfortunately, documentation and on-line resources are scarce.
Does anyone have any pointers to find some resources for this tool?
Hey Jason, believe it or not, Scantron is STILL the standard, but this is not the Scantron you probably remember. Although OMR (bubble) forms are still used extensively in education, there are a lot more advanced technologies available to be added to them today.
Concerning Cognition, I looked through the available tags and these would fit:
"document-imaging" - Cognition is a document imaging product and can feed images and index values into most commercially available document storage applications
"OCR" - Optical Character Recognition, or reading machine print.
"ICR" - Intelligent Character Recognition - reading hand writing, usually in a constrained print format (one letter per box like a credt card application.
"datacollection" - the key purpose of Cognition is data collection.
However, there is not a tag for "OMR" - Optical Mark Recognition, or reading bubble choices, similar to the basic Scantron forms of the past. Also, I could not find one for "Key From Image", another purpose that Cognition is used for.
I am a Cognition user as well as someone who markets it and I know that there are a large number of users in North America. Many corporations that use Cognition use it for sensitive HR functions and so might not have their usage of it posted in a searchable format. Many other organizations use it for safety inspections, insurance data entry, and also for testing and surveys - basically anywhere you have a large number of paper forms and need all of the data quickly entered into a database. Many users are using Cognition for sensitive applications are so are not likely to share, but I can share a few I have, you could also contact your Scantron rep and they might have something they could share as well. I have some decent ICR fields built for name, e-mail, address, etc. The ICR fields are best when you build in your own dictionary or database look-ups. The OMR fields are the hard ones to build, but I have a few of these as well. The easiest way to share these is to send you the form that already has the field built into it. You can build your own lookups from txt, xls or db files.