I have this set of music data crawled from LastFM,
Now, I would like to normalize and classify the songs based on one tag per track. I got this master Genre list, https://spreadsheets.google.com/pub?key=psnjFY3R2itsqjinSs9hkZw
But again, how will I identify, J-pop, JPop and Jap Pop all are same as Japanese Pop? Is there a web api or database which will be useful to get normalized genre?
Thanks for helping.
The tags on LastFM are given by users. Whom (what authority) do you expect to deliver a normalized view on these tags? I guess you can not expect such a service to exist.
Tags are a way to categorize information. You can not prevent users using different tags for the same meaning (e.g. as for japanese pop). If you want to normalize this then you would have to provide a normalization mapping on your own but then again you will not succeed as you would have to include all the new tags created. But how will you know what the different tags are for if the name is not self-explaining.
I suggest to go without a normalization and let the user decide what tags to search for.
When listing songs show all tags don't try to show a normalized view.
Related
I'm building a CRUD for users in my rest API, and currently my GET route looks like this:
get("/api/users/:id")
But this just occured to me: what if a users tries to search for other users via their username?
So I thought about implementing another route, like so:
get("api/users/username/:id")
But this just looks a bit reduntant to me. Even more so if ever my app should allow searching for actual names as well. Would I then need 3 routes?
So in this wonderful community, are there any experienced web developers that could tell me how they would handle having to search for a user via their username?
Obs: if you need more details, just comment about it and I'll promptly update my question 🙃
how they would handle having to search for a user via their username?
How would you support this on a web site?
You would probably have a form; that form would have an input control that would allow the user to provide a user name. When the user submit the form, the browser would copy the form input controls into an application/x-www-form-urlencoded document (as described by the HTTP standard), then substitute that document as the query_part of the form action, and submit the query.
So the resulting request would perhaps look like
GET /api/users?username=GuiMendel HTTP/x.y
You could, of course, have as many different forms as you like, with different combinations of input controls. Some of those forms might share actions, but not necessarily.
so I could just have my controller for GET "/api/users" redirect to an action based on the inputs?
REST doesn't care about "controllers" -- that's an implementation detail; the whole point is that the client doesn't need to know how the server produces a representation of the resource, we just need to know how to ask for it (via the "uniform interface").
Your routing framework might care a great deal, but again that's just another implementation detail hiding behind the facade.
for example, there were no inputs, it would return all users (index), but with the input you suggested, it would filter out only users whose usernames matched the input? Did I get it right?
Yup, that's fine.
From the point of view of a REST client
/api/users
/api/users?username=GuiMendel
These identify different resources; the two resources don't have to have any meaningful relationship with each other at all. The machines don't care (human beings do care, so we normally design our identifiers in such a way that at least some human beings have an easy time of it -- for example, we might optimize our identifiers to make things easy when operators are reading the access logs).
I'm working on a site optimizing their structured data and noticed they use YotPo to pull in ratings and reviews. YotPo is defining the Product and only has a couple of values for AggregateRating that are being injected via JavaScript.
I have all of the other product data coming from the CMS, so I defined all the other information there, but when I run Google's testing tool on the page, it sees it as 2 products and says it's missing fields for the YotPo markup that are already defined in my markup.
Is there some way to let Google know that they're both chunks of data for the same product so it only sees it as a single product with the combined data?
You need to make sure both Yotpo and your CMS use the same format. e.g. json-ld or microdata.
You can then indicate that they relate to the same product by setting both up to use the same id.
Currently, I have an API for showing a list of spots using this route: GET /spots
I also have an API which gets the details for a certain spot: GET /spots/{spot-id}
Now, I will be making another API, which shows all the categories of the spots. Do you guys know of a proper way to go about with this?
So far I have decided on using GET /spots/categories but my manager said it was kind of weird for the spots resource to have categories.
His current suggestions are GET /spot-categories and GET /spotcategories.
Also, for reference, I have database tables spot and spot_category.
Thank you!
I tend to agree with your manager, your spotcategories look like a different entity altogether, so as a resource it deserves a separate url. That being said, if the goal is to find the categories for a particular spot (as opposed to simply browsing through the different available spotcategories), you should only be able to navigate to them through the spots (presuming your API is on level 3 of the Richardson Maturity Model). As in a link from the spots to the categories (or simply embed them, depending on the usage requirements).
So you might end up with something like
GET /spots/{spot-id}/categories
I have added structured data to the product pages of my website. Would it also be beneficial to also add the structured data to the category pages? i.e. the pages that show all products within a certain product category group?
My thought is yes, as I'm describing what that page is displaying. The only doubt I have is that I'm only displaying a subset of the information that's on the full product page. E.g. I don't have a itemprop='description' entry on the category page. But I would assume/hope that because I have itemprop="url" for each product on the category page, that the search engines will be smart enough to tie the two together …?
Yes.
It can be beneficial to have the structured data also on category pages, in sidebars, on search result pages, etc., for various reasons. The more the merrier.
It’s no problem to specify only a subset of the content. Neither Microdata nor Schema.org require any properties.
And yes, by using Schema.org’s url property, you give consumers the chance to learn
that the two items are about the same thing, and
that they might find more properties about the item by following the URL.
(If, or which, consumers actually do this is another topic.)
I'm trying to model a simple, experimental app as I learn Symfony and Doctrine.
My data model requires some flexibility, so I'm currenty looking into the possibility of using either an EAV model, or document store in MongoDB.
Here's my basic requirements:
Users will be able to store and share their favourite things (TV prog, website, song etc).
The list of possible 'things' a user can store is unknown. For example, a user may want to store their favourite animal.
Users can share their favourite things with other users. However, a user can decide what he / she shares with each other user. For example, a user may share their favourite movie with one user, but not another.
A typical user will log in and view all the favourite things from their list of friends, depending on what his friends have decided to share. The user will also update their own favourite things, which will be reflected when each other users views their own profile. Finally, the user may change which of his friends can see what of his favourite thing.
I've worked a lot with Magento, which uses the EAV model extensively. However, I'm adding another layer of complexity by restricting which users can see what information.
I'm instantly drawn to MongoDB as the schemaless format gives me the flexibility I require. However, I'm not sure how easy (or efficient) it will be to access the data once it's saved. I'm also concerned about how changes to the data will be managed, e.g. a user changes their favourite film.
I'm hoping someone can point me in the right direction. This is purely a demo app I'm building to further my knowledge, but I'm treating it like a real-world app where data access times are super-important.
Modelling this kind of app in a traditional relational DB makes me sweat when I think about the crazy number of joins I'd need to get the data for one user.
Thanks for reading this far, and please let me know if I can provide anymore information.
Regards,
Fish
You need to choose a model based on how you need to access the data.
If you just need to filter out some values when viewing the user profile, a single document for each user would work quite well, with each favorite within that having a list of authorized user/group IDs that is applied in the application code. Both read and write are single operations on a known document in this case, so will be fast.
If you need views across multiple profiles though, your main document should probably be the favorite. You'll need to set up the right indexes, but performance shouldn't be a problem.
Actually, the permissions you describe don't add that much complexity to an EAV schema - as long as attributes can have multiple values the permissions list is just one more attribute.