I want to update my web applications to use JSON-LD so that they get better on the search engines.
I read a lot on the JSON-LD website and the Google documentation about it but all of it deals with using a single entity.
What if on a single page -like my home page- I want to output TWO entities? For example the ORGANIZATION entity and the WEBSITE entity so that I can indicate the name of the site (and its alternate name) as well as the social site links that are also "same as" the web site?
When I tried appending them with a comma and tried it on the testing tool, it only "received" the first entity in the list
UPDATE
This is not a duplicate. For those who read carefully they will see that I am talking about TWO different entities being specified. The suggested duplicate is about a single entity with multiple (array) sub-attributes. That is not my case, mine is about multiple top level entities (Organization and Person for example).
After a much deeper search with variations on the search words I managed to get my answer here: enter link description here
So basically, if the entities/types are DIFFERENT as in my question (and unlike what the reviewer thought), then you must use separate script tags for each JSON+LD entity/type.
Related
I would like to implement facebook - like news feed for my website, with social functionalities, such as share, like, comment and post and I want to connect it to already created users (nice to have it connected with Azure Active Directory).
Is there any ready solution for this problem?
Thanks in advance!
I don't know of anything specific, and StackOverflow is not the place for generalized library recommendations. However, it should be trivial enough to implement yourself. Activity streams are composed of four main components:
Actor
Verb
Object
Target
For example: "John (actor) shared (verb) a photo (object) with Mary (target)."
Just create an entity that can track these four aspects, and then add a record describing the action each time something happens. By making certain parts foreign keys (actor/target could be foreign keys to your user table), you can then pull actions specifically related to a particular user or other object in your system.
First of all, I want to apologize for my terminology. I am not entirely sure what to call what I am looking for, so I can’t google for answers. But here is my problem.
I am working on a Rails application that stores information about different websites and provides various services for them. I will call these services ‘Products.’ One website can be subscribed to several products, and a product can be served to various websites. So here is a very simple association scheme for these relationships:
At least, it would have been simple, but the problem is that the Settings model (shown in red on this diagram) is different for each product: for one product, it will have one number of fields and data types, for another it will have a different number of fields with different data types. On the other hand, the Faq and Description are the same, so if I redraw the diagram as follows:
I will get another problem: too much repetition (shown in blue on the diagram). Ideally, I want some kind of modification of the first diagram, where the Product model will choose differens Settings models depending on a parameter that I pass to it:
So that a request website.products.find(1).settings will return the model Settings1, while a request website.products.find(2).settings will return a completely different model, Settings2.
Is this achievable in Rails? If not, how would you organize such data?
I have a multiple site Sitecore solution. All the sites share a product range which is stored inside a 'Shared data' node that sits at the same level as the root nodes of the sites. The individual product pages on a site use a wildcard item to lookup the product based on the last part of the URL.
This means that we can't use internal links in the rich text editor to point to the product page on any of the sites because the product item does not have a specific site URL.
Does anyone know of a way to overcome this, or perhaps know of a way to augment the default behavior of interal links?
Have you considered using cloned items, see here for details.
This would allow you to share the content whilst having the appearance to the end user of the Products being inside the content tree allowing you to use the RTE and internal link look ups?
For extra information about clones, see here and here
You'd also need to do some work in the link provider to link to the cloned version of a product if you wanted. See this question.
I am using embedded documents in MongoDB for a Rails 3 app. I like that I can use embedded documents and the values are all returned with one query and there is less load on the database server. But what happens if I want my users to be able to update properties that really should be shared across documents. Is this sort of operation feasible with MongoDB or would I be better off using normal id based relations? If ID based relations are the way to go would it affect performance to a great degree?
If you need to know anything else about the application or data I would be happy to let you know what I am working with.
Document that has many properties that all documents share.
Person
name: string
description: string
Document that wants to use these properties:
Post
(references many people)
body: string
This all depends on what are you going to do with your Person model later. I know of at least one working example (blog using MongoDB) where its developer keeps user data inside comments they make and uses one collection for the entire blog. Well, ok, he uses second one for his "tag cloud" :) He just doesn't need to keep centralized list of all commenters, he doesn't care. His blog contains consolidated data from all his previous sites/blogs?, almost 6000 posts total. Posts contain comments, comments contain users, users have emails, he got "subscribe to comments" option for every user who comments some post, authorization is handled by the external OpenID service aggregator (Loginza), he keeps user email got from Loginza response and their "login token" in their cookies. So the functionality is pretty good.
So, the real question is - what are you going to do with your Users later? If really feel like you need a separate collection (you're going to let users have centralized control panels, have site-based registration, you're going to make user-centristic features and so on), make it separate. If not - keep it simple and have fun :)
It depends on what user info you want to share acrross documents. Lets say if you have user and user have emails. Does not make sence to move emails into separate collection since will be not more that 10, 20, 100 emails per user. But if user say have some big related information that always growing, like blog posts then make sence to move it into separate collection.
So answer depend on user document structure. If you show your user document structure and what you planning to move into separate collection i will help you make decision.
I am building an mvc 3 application that will be multi-tenant, which means it will use the same basic data structure, but provide different data depending on the domain name used to access it.
A problem I am trying to solve is this. How best do I populate a number of dropdown lists with selection choices based on the site being rendered. To add another wrinkle, I will need to localize the strings as well.
An obvious choice is to simply create a table with columns for website id and language id, plus field id and string value. This seems ok, but also seems to ignore possible mechanisms that are already in place for localization. I feel like i'm recreating the wheel here.
As an example, site 1 might have a dropdownlist for Favorite Activities, and have ranges items that are geared toward musical interests. Site 2 might have the same dropdown, but have items geared for sports intersts.
So my question is, how would you go about solving this problem? Also, in a similar vein... If you have selection lists, say State codes, cities, etc.. would you tend to create seperate tables to populate this data (states table, cities table, etc..) or would you put all this information in a common table and have an ID to indicate which dropdown it was to be used for? The former seems more normalized, but the latter seems more efficient (less code to write).
Thoughts about Common Lookup Tables. This guy is definitely against.
http://www.projectdmx.com/dbdesign/lookup.aspx
I have used it and believe that I have saved some time, or at least some keystrokes. Might be sorry later on.