I want to use json ld micro-data from schema.org to reference images on my website but at the same time retrieve the json ld object in my Javascript to use it for others things. The problem is that I want to add custom fields that do not match any type in Schema.org. My question is, will search engines just ignore the fields they don't recognize or discard the whole micro-data ?
Short answer, yes they’ll ignore properties they don’t define, and it’s quite normal to use JSON-LD for other purposes, such as to drive your UI. That said, it’s best if these properties and types come from a known vocabulary, or even resolve to your own. It’s always good to test your data patterns first, using any of the online tools available.
Also, it’s not JSON-LD micro-data, they are actually two different things, both of which (along with RDFa) can be used to provide schema.org markup. JSON-LD is contained in a script element, the others are expressed using HTML attributes.
Related
I’m writing a web application in Perl. It has a form containing contact information, and is currently laid out something like this:
$form_htm = <<EOF
<input value="$in{firstname}" name="firstname">
<input value="$in{surname}" name="surname">
...etc...
EOF
Later on I print $form_htm (amongst other things) to display the webpage.
The above is working for me, and the fields are interpolated as expected.
However, I’d like different organisations who use this application to be able to have a different layout for their fields. Some fields won't apply to some organisations, and some organisations will want different sizes (on the web page) for fields than others.
So, I thought I’d store the HTML for the form in a database (different versions in different records for different organisations).
But because the HTML is not stored in the script, the fields (like $in{firstname}) are not interpolated, so the variable names themselves are ending up on the web page, (which is not quite the look I’m after).
Any recommendations on how I should get these variables to be evaluated in this context? (First thing that came to mind is eval(), but that seems aimed at evaluating expressions, not variables mixed in with a lot of other text.)
Or can you suggest a better approach to allow for different form layouts for different organisations?
Edit: I have also posted this question on Perl Monks, but would like to get other opinions.
Here's some bad ways and some good ways to handle this.
The Bad Ways
Stick HTML in your code.
my $form_htm = <<EOF
<input value="$in{firstname}" name="firstname">
<input value="$in{surname}" name="surname">
...etc...
EOF
This was a very common thing to do. It has major problems. First, it welds together the logic of the program with what is displayed. There's either only one way to display it, or your code gets increasingly complicated trying to allow multiple ways to display it. You're running into this problem.
Second, it means in order to change how it looks you need a developer involved. You can't have separate UX people working on the HTML and CSS layout, they also need to know Perl or get a Perl developer involved. This makes it very expensive and slow to make otherwise simple HTML changes.
Third, with the code to generate the HTML scattered around it makes it difficult to figure out how each page comes to be. If you want to change a form in a page, you have to hunt around in the code to find how it's generated.
Fourth, it's slow. Every single page has to be generated by the server.
Stick code in your HTML.
<%class>
has 'amount';
has 'name';
</%class>
Dear <% $.name %>,
We are pleased to inform you that you have won $<% sprintf("%.2f", $.amount) %>!
Sincerely,
The Lottery Commission
<%init>
die "amount must be a positive value!" unless $.amount > 0;
</%init>
This what PHP and Mason do. It's better than sticking HTML in your code, but it still has major problems. It can be used well, but it encourages you to put WAY too much logic into the templates. This scatters the logic around making it hard to understand what's going on. Code in the templates is hard to document and test. It also mixes code into the templates which again blurs the line between UX person and developer.
The Good Ways
MVC: Model-View-Controller
Model-View-Controller provides a clear delineation between the data and logic (the "model") and how it's displayed (the "view"). These are connected with a bit of code to get data from the model and send it off to the view as variables (the "controller").
This is one of the most successful ways of putting together a web site. Ruby On Rails and Catalyst are built around this.
I'd recommend Dancer. It's much smaller and easier to understand than Catalyst. Since it provides less it's easier to adapt an existing program to use it. It provides the view and controller, the model is up to you.
There's two good ways to put together the view.
An HTML Template.
The usual way is to put your entire HTML page in a template, much like we saw before, but instead of it having its own code for getting data it's instead passed data to use. It has a limited language for manipulating that data.
In Perl this is generally Template Toolkit.
Dear [% name %],
It has come to our attention that your account is in
arrears to the sum of [% debt %].
Please settle your account before [% deadline %] or we
will be forced to revoke your Licence to Thrill.
The Management.
Now UX people can manage HTML templates on their own. They still have to learn a template language, but it's at least a well documented one. The limited language discourages putting too much code in the templates creating a sort of firewall between the View and the rest of the code.
But all the work to format the template still must be done on the server side. And UX people still have to learn a special template language. Which brings us to the best way.
Pure HTML, CSS, and Javascript.
In this mode, instead of processing a template on the server side and inserting variables into it, the HTML has Javascript which requests the data it needs and displays it as it sees fit. This has great advantages.
It completely divorces the view from the rest of the code. This gives the UX folks great control over how the application behaves. They decide what data each page needs. They decide how it's manipulated and displayed. Developers can focus on providing the data.
The other advantage is using Javascript. Javascript has become the defacto programming language that web designers must know. UX folks don't need to learn a special template language, they use the same HTML, CSS, and Javascript they've always used.
Finally, this means the bulk of the formatting work is done on the client side reducing the load on your server.
The main disadvantage is this requires a major re-architecture of an existing system. Instead of producing HTML pages, your server code now produces JSON for the Javascript to manipulate via REST requests.
Hybrid Template + Javascript
A good hybrid for an existing system is to use templates, but instead of using a special template language, use Javascript. Simple scalar variables like names and amounts can still be provided as template variables, but larger units like lists and hashes are injected into the template as JSON.
For example, this template...
var people = [% people %]
would be provided with people = encode_json(\#people)' and it might expand to:
var people = ["Jack", "Jill", "Jane", "Joe"]
Then the UX person can do whatever they want with this Javascript people array.
On the downside, this still gives the developers too much control over how the site works, because they decide what templates are used and what data they're given, and it still means the templates have to be expanded server side.
On the upside it lets UX people manipulate that data in ways they're comfortable with, it enforces a clear separation between the view and the rest of the code, and you can convert existing code to use these sorts of templates a piece at a time.
Are there any advantages/disadvantages in using a specific format for http://www.schema.org/Product? Something like "Searchengines understand Microdata better than JSON-LD"? I would like to use JSON-LD, because it doesn't mess-up with your html-code, but I'm not sure if it would be better concerning the searchengines to use Microdata.
There is no general answer, it depends on the consumer of the data.
A specific consumer supports a specific set of syntaxes, and might or might not recommend a subset of these supported syntaxes.
Because search engines usually try to make sure not to get lead astray (e.g., a page about X claims via its Schema.org use to be about Y), it seems natural that they would prefer a syntax that couples the Schema.org metadata to the visible content of the page (in HTML5, this would be Microdata or RDFa); for the same reasons why many meta tags are dead for SEO.
However, this is not necessarily always the case. Google, for example, recommends the use of JSON-LD for a few of their features (bold emphasis mine):
Promote Critic Reviews:
Though we strongly recommend using JSON-LD, Google can also read schema.org fields embedded in a web page with the microdata or RDFa standards.
Sitelinks Search Box:
We recommend JSON-LD. Alternatively, you can use microdata.
I have already done all the I18N and GetText things in multiple languages for an existing site.
For selecting one language or another it seems that prefixing urls with path parts like www.domain.com/fr_FR/my_action or www.domain.com/de_DE/my_action is the best way to go, gor Google friendly sites.
I have found this module: Catalyst-Plugin-I18N-PathPrefix And seems to be based on this advent article
Is it the right way (or current best practice) to do this in Catalyst?
It promises that I do not need to change my actions, my required arguments and urls.
Or this plugin/technique makes a overload in the server that I can better avoid rewriting all my urls by hand?
Regards:
Migue
Are www.domain.com/fr_FR/my_action and www.domain.com/de_DE/my_action the same resource, just represented in
different languages? Or would your users see different contents depending on the language they choose (like, I don't know, different news)?
If the answer to the first question is yes I'd rather go for implementing Accept-language header compliance, for example using I18N::AcceptLanguage, which has the additional benefit that it won't interfere in any way with how you designed your URLs.
I take the risks and implemented the Catalyst-Plugin-I18N-PathPrefix plugin. It was easy, and the server load (that was my main concern) seems to be unnoticeable.
Lets say... I should use time to optimize a lot of things of my own code before be concerned about the plugin performance.
Thank you, anyway.
Mainly, I was wondering what advantages the ontology languages of RDFS/OWL has over using a markup system (such as http://www.schema.org/) for managing and creating metadata?
I'm still very confused about how different concepts of the "Semantic Web" are supposed to fit together in the overall picture... The relation between RDF/RDFS/RDFa? OWL? URIs? and finally, XML and SQL/SPARQL? All the descriptions I've read about so far about them make sense individually, but I'm not sure if I could be able to use them as tools if someone were to tell me to implement and query an ontology, for instance. Or any simple examples that can be provided is greatly appreciated.
So Webster Thesaurus followed ashutosh raina's advice and went to answers.semanticweb.com. To facilitate retrieval of the corresponding question there, here is the link: What's the difference between using RDFS/OWL versus XML?
There should be a script redirecting all questions with the "semantic-web" tag to answers.semanticweb.com ;)
We're reworking some APIs and are considering a REST-style approach, but we're realizing we aren't sure how to deal with certain situations (lists of resources with parameters that influence what is selected, etc.), or even how to effectively structure urls for resources that may be referred to by themselves but are conceptually subordinate to some other entity (think users/posts/comments, but with even more complicated relationships).
We've seen a lot of material on structuring REST APIs for simple cases, but what material is available that talks extensively about making these choices in more real-world scenarios?
First, it's important to note here that REST is an architecture, which means that it simply describes a strategy to follow for addressing and working with resources. It doesn't say how to implement that strategy, or even how to tell if somebody's being RESTful or not.
I also think you're overcomplicating things a bit. Here's a more precise answer for your two specific questions:
how to effectively structure urls for resources that may be referred to by themselves but are conceptually subordinate to some other entity (think users/posts/comments, but with even more complicated relationships)
Even if something is subordinate to something else conceptually, that doesn't necessarily matter for purposes of describing it. For example, let's use your blog example. A Blog may have many Articles, each of which may have one or more Pictures. At first crack, you might expect to be able to reference Pictures with something like:
http://api.example.com/articles/123/pictures/456
But notice that, since Pictures are resources themselves, there's nothing wrong with just doing:
http://api.example.com/pictures/456
(lists of resources with parameters that influence what is selected, etc.)
It's perfectly normal and acceptable to have parameters in a RESTful request. For example, say you want to get the first 500 pictures by date, starting from the twenty-fifth such picture. Your API might support something like this:
http://api.example.com/pictures?limit=500&offset=25&order=desc&by=date
If you can be more precise with you questions, there are plenty of people here who will attempt to help.
Otherwise, here are a few other resources that should be useful.
REST Discuss Mailing List
Rest Wiki
REST Cookbook
The best piece of advice I can give you though, is to stop thinking about how to structure URLs and focus on what links you are going to put in your representations. How to structure your URLs will be easy once you have figured out your media types.
I'll go ahead and assume we're talking about RESTful HTTP :)
This is how you would expose a "list of resources with parameters that influence what is selected":
/list?{search part}
Where the search part is some arbitrary string which you use to target a 'section' of the list resource.
The common way to do this (the way that browsers + html forms work) is to have key/value pairs for each parameter i.e:
/list?name1=fred&name2=dave&name3=matt
This convention for arranging your search part is not mandatory but you will find that following this pattern makes it easier to write HTML for your app. It would be no less valid in terms of HTTP and URI to use the following:
/list?fred,dave,matt
how to effectively structure urls for
resources that may be referred to by
themselves but are conceptually
subordinate to some other entity
In REST there is no such thing as 'structured' URIs. A URI is simply a unique identifier - similarities and patterns in URI structure can make organising server side logic easier and make it 'pretty' for users to look at and figure out - but if you're doing REST there is no relationship between the following:
/foo
/foo/bar
.. unless you create a relationship with a hyperlink from one to the other. This rule of thumb is generally referred to as the 'hypertext constraint' or 'HATEOAS'.
Having said that - there's nothing wrong with 'prettying' up your URIs. Just be aware that (if you want to 'do REST') you should be linking everything together. Most APIs expose 'nested resources' like this:
/countries/england/cities/london
Hope that's helpful :-)