While I am trying to understand what semantic web is and what technologies are used, I saw from https://en.wikipedia.org/wiki/Semantic_Web#Semantic_Web_solutions
The Semantic Web takes the solution further. It involves publishing in
languages specifically designed for data: Resource Description
Framework (RDF), Web Ontology Language (OWL), and Extensible Markup
Language (XML). HTML describes documents and the links between them.
RDF, OWL, and XML, by contrast, can describe arbitrary things such as
people, meetings, or airplane parts.
In Semantic web,
is HTML not used at all, and is XML used instead?
Is the principle of separation of semantics (content) from presentation in HTML not related to semantic web?
Is JSON not used and is XML used instead?
JSON is overwhelmingly used for representing data than XML, and if semantic web uses XML, does it mean that semantic web is not a trend?
In related tags to semantic web, I find more HTML tag than XML tag, and can't find JSON tag.
RDF is conceptually a graph database with OWL providing logic features (axioms for extending a ground RDF graph with additional induced tuples such as for transitivity). RDF has per se nothing to do with markup (XML, SGML, HTML) but RDF/XML is one of several standardized serialization formats for an RDF graph, another one being turtle/N3.
However, RDF was specifically introduced to represent semantic data on the Web. Hence, there are additional serialization formats for RDF graphs in Web documents: RDFa for embedding RDF data in HTML or XML documents, and JSON-LD as a JSON format for serializing RDF graphs (with a focus on linked data).
The term "semantic web" refers primarily to a concept, rather than a particular implementation of that concept.
Over time, various standards have been developed and implemented with the aim of implementing the concept, and in particular the W3C has a long-running project to create a stack of such standards covering the requirements they see for a successful semantic web. The W3C tries to build standards on top of each other, and sees XML as the base on which much of the rest of their work is based, so their definitions often use an XML syntax.
In practice, though, HTML is overwhelmingly the language of the web, and XHTML (an attempt to re-specify HTML as an XML-based standard) is considered to have failed. As such, HTML-based technologies such as "microformats" (metadata embedded in HTML via specific patterns of markup) are a popular alternative to more strictly machine-oriented XML formats, and are often designed to interact with them.
Similarly, JSON became popular as a light-weight data interchange format without the perceived complexity of XML and XML-based document standards. Over time, tools have been built to formalise and work with JSON, some of which may well be involved in "semantic web" concepts.
I think an important distinction is between the low-level markup format of data - XML, HTML, JSON - and the higher-level technologies being implemented. For instance, RDF can be written in various "concrete syntaxes"; one of those is an XML-based markup, but others are designed to be "human-readable" (Turtle/N3), embedded in HTML (RDFa) or combined into a JSON format (JSON-LD). The same is true of other standards, such as OWL. It is therefore somewhat misleading to think about "using XML instead of HTML or JSON"; the real distinction might be more like "using an Ontology definition rather than a document template".
Related
Blogger blogs use XML, and Tumblr blogs use HTML, but they both do the same thing. What is the difference between XML and HTML and what are the pros and cons of using them?
HTML is a markup language for describing hypertext ("with links") documents.
XML is a generic markup language designed for using as a base for building custom markup languages.
They are different tools for different jobs.
When you write a template for either Blogger or Tumblr, you are using a template language. Blogger's template language happens to be built in XML. The template language is combined with your data to generate the HTML documents that are sent to the browser.
XML was developed to describe data and to focalize on what the data represent.
HTML was developed to display data about to focalize on the way that data looks.
HTML is about displaying data, XML is about describing information.
Reference
In an ideal world, HTML would be just one of many XML vocabularies. The only reason it isn't is history: (a) it was wild on the web before XML was formulated, and (b) it developed a culture where you could write any old garbage and the browsers would try and make sense of it, whereas XML insisted that you stick to the rules.
The W3C spent about ten years trying to make this vision happen, through the medium of XHTML, but in the end the browser vendors decided to go their own way.
XML was developed to describe data and to focalize on what the data represents.
Whereas HTML describes the structure of Web pages using markup.
In other words, HTML is used to display data, XML is used to store and transport data.
The content tends to be mixed with it's form when expressed as a HTML+CSS+JS document. Almost every modern website requires CSS and/or JavaScript to be readable. Most of them are not easy to parse automatically because they relay on web browser to render it. Sections of the document are defined using visual clues, colors and formatting. One can use HTML5 tags like <article> but those are not a part of any bigger structure as far as I know, and still can contain non-content elements.
Websites are basically apps or clients.
Is there any standard that can be used to serve content of a website that has a well defined schema? An API for websites that could be used to express content in the form that is easy to server, parse, store, cryptographically sign...
I'm aware of formats like XML and JSON but I have not managed to find any standardized way to express a blog post as a JSON document.
An example of what I have in mind:
This question can be fetched as an JSON document using Stackexchange API. The result is machine readable and easy to parse but is in not standardized. It reflects details of Stackexchange specific data structures. Other QA website will have different API, with different structure and formats even though both have questions and answers.
There are two important standards out there dealing with the semantic aspect of a web page, like the one you are looking for. Microdata and RDFa. With their aid, you can pick a certain open vocabulary to describe your data or create your own based on them.
With JSON-LD also, you can create a schema for JSON documents like the XML schema is for the XML documents.
I have a quick question about RDFa and Microdata.
My current understanding is that RDFa is RDF implemented into HTML but is complicated for new developers like myself, Microdata seems really easy and quick to implement.
What are the other advantages and disadvantages around these two semantic formats ?
Differences between Microdata and RDFa
While there are many (technical, smaller) differences, here’s a selection of those I consider important (used my answer on Webmasters as a base).
Specifications
As W3C’s HTML WG found no volunteer to edit the Microdata specification, it is now merely a W3C Group Note (see history), which means that there are no plans for any further work on it.
So the Microdata section in WHATWG’s "HTML Living Standard" is the only place where Microdata may evolve. Depending on what gets changed, it may happen that their Microdata becomes incompatible to W3C’s HTML5.
Update: In 2017, work started again, with the aim to publish Microdata as W3C Recommendation.
RDFa is published as W3C Recommendation.
Applicability
Microdata can only be used in (X)HTML5 (resp. HTML as defined by the WHATWG).
RDFa can be used in various host languages, i.e. several (X)HTML variants and XML (thus also in SVG, MathML, Atom etc.).
And new host languages can be supported, as RDFa Core "is a specification for attributes to express structured data in any markup language".
Use of multiple vocabularies
In Microdata, it’s harder, and sometimes impossible, to use several vocabularies for the same content.
Thanks to its use of prefixes, RDFa allows to mix vocabularies.
Use of reverse properties
Microdata doesn’t provide a way to use reverse properties. You need this for vocabularies that don’t define inverse properties (e.g., they only define parent instead of parent & child). The popular Schema.org is such a vocabulary (with only a few older exceptions).
While the W3C Note Microdata to RDF defines the experimental itemprop-reverse, this attribute is not part of W3C’s nor WHATWG’s Microdata.
RDFa supports the use of reverse properties (with the rev attribute).
Semantic Web
By using Microdata, you are not directly playing part in the Semantic Web (and AFAIK Microdata doesn’t intend to), mostly because it’s not defined as RDF serialization (although there are ways to extract RDF from Microdata).
RDFa is an RDF serialization, and RDF is the foundation of W3C’s Semantic Web.
The specifications RDFa Core and HTML+RDFa may be more complex than HTML Microdata, but it’s not a "fair" comparison because they offer more features.
Similar to Microdata would be RDFa Lite (which "does work for most day-to-day needs"), and this spec, at least in my opinion, is way less complex than Microdata.
What to do?
If you want to support specific consumers (for example, a search engine and a browser add-on), you should check their documentation about supported syntaxes.
If you want to learn only one syntax and have no specific consumers in mind, (attention, subjective opinion!) go with RDFa. Why?
RDFa matured over the years and is a W3C Rec, while Microdata is a relatively new invention and not standardized by the W3C.
RDFa can be used in many languages, not only HTML5.
RDFa allows mixed use of vocabularies for the same content, and it natively supports the use of reverse properties.
Can’t decide? Use both.
Note that you can also use several syntaxes for the same content, so you could have Microdata and RDFa (and Microformats, and JSON-LD, and …) for maximum compatibility.
Here’s a simple Microdata snippet:
<p itemscope itemtype="http://schema.org/Person">
<span itemprop="name">John Doe</span> is his name.
</p>
Here’s the same snippet using RDFa (Lite):
<p typeof="schema:Person">
<span property="schema:name">John Doe</span> is his name.
</p>
And here both syntaxes are used together:
<p itemscope itemtype="http://schema.org/Person" typeof="schema:Person">
<span itemprop="name" property="schema:name">John Doe</span> is his name.
</p>
But it’s typically not necessary/recommended to go down this route.
The main advantage you get from any semantic format is the ability for consumers to reuse your data.
For example, search engines like Google are consumers that reuse your data to display Rich Snippets, such as this one:
In order to decide which format is best, you need to know which consumers you want to target. For example, Google says in their FAQ that they will only process microdata (though the testing tool does now work with RDFa, so it is possible that they accept RDFa).
Unless you know that your target consumer only accepts RDFa, you are probably best going with microdata. While many RDFa-consuming services (such as the semantic search engine Sindice) also accept microdata, microdata-consuming services are less likely to accept RDFa.
I'm not certain if unor's suggestion to use both Microdata and RDFa is a good idea. If you use Google's Structured Data Testing Tool (or other similar tools) on his example it shows duplicate data which seems to imply that the Google bot would pick up two people named John Doe on the webpage instead of one which was the original intention.
I'm assuming therefore that using one syntax for a given item is a better idea (you should still be able to mix syntaxes as long as they describe separate entities).
Though I would be happy to be proven wrong on this.
I would say it largely depends on the use case: For Scientific use cases, RDF is common and used in different aspects.
For enriching Websites, JSON-LD is now recommended, for example by Google.
A JavaScript notation embedded in a tag in the page head or
body. The markup is not interleaved with the user-visible text, which
makes nested data items easier to express, such as the Country of a
PostalAddress of a MusicVenue of an Event. Also, Google can read
JSON-LD data when it is dynamically injected into the page's contents,
such as by JavaScript code or embedded widgets in your content
management system.
So, yeah, is HTML a particular application of XML? Like, instead of user-customizable tags, "hard coded" fixed tags decided by the W3C and interpreted by navigators? Or are them totally different things?
Also, in which case is XML better than a database to transfer information inside a Web application? (I was thinking, saving users information or things like that may do better with XML documents than with a database).
Here's a history of HTML
...The HTML that Tim invented was strongly based on SGML (Standard Generalized Mark-up Language), an internationally agreed upon method for marking up text into structural units such as paragraphs, headings, list items and so on. SGML could be implemented on any machine. The idea was that the language was independent of the formatter (the browser or other viewing software) which actually displayed the text on the screen. The use of pairs of tags such as and is taken directly from SGML, which does exactly the same. The SGML elements used in Tim's HTML included P (paragraph); H1 through H6 (heading level 1 through heading level 6); OL (ordered lists); UL (unordered lists); LI (list items) and various others. What SGML does not include, of course, are hypertext links: the idea of using the anchor element with the HREF attribute was purely Tim's invention, as was the now-famous `www.name.name' format for addressing machines on the Web....
And in no case is XML "better" than a database (are cakes better than ovens?). XML isn't for storing data, it's for transfering it. Unless the data is absolutely minimal, you have to find some other way to store it. Opening static XML files on the file system over and over as you save and read data is a terrible way to go about it.
So, yeah, is HTML a particular application of XML?
No.
HTML 4 is an application of SGML, but most parsers for it do not treat it as such.
XHTML is an application of XML, but it is usually served as text/html instead of application/xhtml+xml and so is treated like HTML.
HTML 5 is not an application of either SGML or XML (except in its XML serialisation) and has its own parsing rules.
Also, in which case is XML better than a database to transfer information inside a Web application?
XML is a good basis for a data exchange format. It is not a good basis for storing data in order to search it (which is what happens "inside" most web applications)
HTML and XML both come from SGML, hence their similarities. But XML is a strict grammar (no predefined tag names), while HTML is both a not very strict grammar and a vocabulary (tag names). There is an HTML variant which strictly complies with XML rules : XHTML.
As for using XML as a database, it is possible under certain circumstances. But it really depends on your architecture, language, volumetry and lots of other considerations. I suggest you open a new question with more details for this.
XHTML is a reformulation of HTML as XML app.
You can invent your own tags. I don't think HTML5 has a doctype for that though. You can create them with JavaScript and initalize/style then with CSS like any other element.
instead of using XML, spit out JSON, seriously, do this.
if you are worried about using your db, think about switching to couchdb or nosql. they're ripe for JSON.
don't get me wrong, your thought process isn't wrong, you can do that. i've seen it done rather well. but most people don't get it right. and seriously, JSON is your friend.
For the differences between HTML & XML see:
http://www.w3schools.com/xml/xml_whatis.asp
XML is primarily used for transfering data, not storing it. A database will generally give you much more flexibility in querying the data.
HTML allows things that XML doesn't allow, like omitting end tags, omitting the quotes around attribute values, and using upper-case and lower-case interchangeably. So HTML is not just another XML vocabulary.
XHTML, however, was an attempt to reformulate HTML as an XML vocabulary.
Reading some related questions made me think about the theoretical nature of HTML.
I'm not talking about XHTML-like code here. I'm talking about stuff like this crazy piece of markup, which is perfectly valid HTML(!)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html<head>
<title//
<p ltr<span id=p></span</p>
</>
So given the enormous complexity that SGML injects here, is HTML a context-free language? Is it a formal language anyway? With a grammar?
What about HTML5?
I'm new to the concept of formal languages, so please bear with me. And yes, I have read the wikipedia article ;)
Context Free is a concept from language theory that has important implications in parser implementation. A Context Free Language can be described by a Context Free Grammar, which is one in which all rules have a single non-terminal symbol at the left of the arrow:
X→δ
That simple restriction allows X to be substituted by the right-hand side of the rules in which appears on the left without regard to what came before or after. For example, if while deriving or parsing one arrives at:
αXλ
one is sure that
αδλ
is also valid. Examples of non-context-free rules would be:
XY→δ
Xa→δ
aX→δ
Those would require knowing what could be derive arround X to determine if a rule applies, and that leads to non-determinism (what's around X would also like to know what it derives to), which is a no-no in parsing, and in any case we want a language to be well-defined.
The only way to prove that a language is context-free is by proving that there's a context-free grammar for it, which is not an easy task. Most programming languages one comes about are already described by CFGs, so the job is done. But there are other languages, including programming languages, that are described using logic or plain English, so work is required to find if they are context-free.
For HTML, the answer about its context-freedom is yes. SGML is a well defined Context Free Language, and HTML defined on top of it is also a CFL. Parsers and grammars for both languages abound on the Web. At any rate, that there exist LL(k) grammars for valid HTML is enough proof that the language is context-free, because LL is a proven subset of CF.
But the way HTML evolved over the life of the Web forced browsers to treat it as not that well defined. Modern Web browsers will go out of their way to try to render something sensible out of almost anything they find. The grammars they use are not CFGs, and the parsers are far more complex than the ones required for SGML/HTML.
HTML is defined at several levels.
At the lexical level there are the rules for valid characters, identifiers, strings, and so on.
At the next level is XML, which consists of the opening and closing <tags> that define a hierarchical document structure. You can use XML or something XML-like for any purpose, like Apache Ant does for build scripts.
At the next level are the tags that are valid in HTML, and the rules about which tags may be nested within which tags.
At the next level are the rules about which attributes are valid for which tags, languages that can be embedded in HTML like CSS and JavaScript.
Finally, you have the semantic rules about what a given HTML document means.
The syntactic part is defined well enough that it can be verified. The semantic part is much larger than the syntactic one, and is defined in terms of browser actions regarding HTTP, and the Document Object Model (DOM), and how a model should be rendered to the screen.
In the end:
Parsing correct HTML is extremely easy (it's context-free and LL/LR).
Parsing the HTML that actually exists over the Web is difficult.
Implementing the semantics (a browser) over HTML/CSS/DOM is extremely difficult.
Valid HTML is not a context-free language.
First of all, HTML being an application of SGML is fiction for all practical purposes, so analyzing SGML to answer the question is useless. (However, the SGML fiction probably isn't context-free, either.)
It's more useful to look at the actually defined HTML parsing algorithm. It works on two levels: tokenization and tree building. What HTML calls tokenization is a higher-level operation than what is usually called tokenization when talking about parsers. In the case of HTML, tokenization splits a stream of characters into units like start tags, end tags, comments and text. The tokenizer expands character references. Usually, when talking about parsers, you'd probably treat stuff like the less-than sign as "tokens" and would consider character references to consist of tokens instead of being resolved by the tokenizer.
If you consider the process of splitting the input stream into tokens, that level of the HTML language is regular (except for feedback from the tree builder).
However, there are three complications: The first one is that splitting the input stream into tokens is just the first and then there's the tree builder's side that actually cares about the identifiers in the tokens. The second one is that the tree builder feeds back into the tokenizer so that some state transitions made by the tokenizer depend on the state of the tree builder! The third one is that valid documents in the language are defined by rules that apply to the output of the tree builder stage and those rules are complex enough that they can't be fully defined using tree automata (as evidenced by RELAX NG not being expressive enough to describe all the validity constraints).
This isn't an actual proof, but you can probably develop real proofs by working from complications #2 and #3.
Note that the case of invalid documents is not particularly interesting as a question of whether the language is context-free in the sense of there being a context-free grammar that generates all the possible strings with no regard to the parse tree having some intelligible interpretation in terms of the tree that an HTML parser generates. The HTML parser will successfully consume all possible strings, so in that sense, all possible strings are in the "invalid HTML" language.
Edit: Interesting questions left as exercise to the reader:
Is HTML without parse errors but ignoring validity a context-free language?
Is HTML without parse errors and ignoring general validity but with only valid element names allowed a context-free language?
(Complication #2 applies in both cases.)
NO
See Edit Below
It depends.
If you are talking about the subset consisting of only theoretical HTML, then yes.
If you also include real life, working HTML that is accessed and used successfully by millions of people daily on many of the top sites on the internet then NO.
That is what gives HTML flexibility. The parsing engine adds tags, closes tags, and takes care of stuff that a theoretical CFG can't do. If you took automata you might remember that a production rule in a formal grammar cannot be empty (aka epsilon/lambda) on the lhs (left-hand side). Since the parsing engine is basically using knowledge that a formal grammar and automata couldn't have, it isn't restricted by that and the 'grammar' would have epsilon/lambda -> result where the specific epsilon/lambda rule is chosen based on information not available in the grammar.
Since I don't think empty lhs are allowed in any formal grammars, HTML cannot be defined by a formal grammar and is not a formal language at all.
Sure, HTML5 might try to move towards a 'more formal' language description but the likelihood that it becomes a context free language in reality (i.e. strings not matched by the grammar are rejected) is about the likelihood XHTML 2.0 takes the world by storm and replaces HTML altogether (XHTML is the attempt they made to make HTML a formal language...it was rejected en masse due to its fragility).
Noteworthy is the fact that HTML 5 is the FIRST HTML standard to be defined before being implemented! That's right, HTML 1-4 consist of random ideas someone just implemented in a browser, and were collected into standards after the fact based on which features were popularly used and widely implemented. Then they tried XHTML, which totally failed to be adopted. Even 'xhtml' on the web is automatically parsed as HTML under almost every circumstance to prevent stuff from just breaking with a cryptic syntax error. Now you can see how we got here and why it is unlikely to be formalized any time soon.
Lesson: "In theory, there is no difference between theory and practice. In practice, there is." - Yogi Berra
EDIT:
Actually, after reading through the documents it turns out that HTML, even according to the HTML 4.01 specification, doesn't actually conform to SGML. To see for yourself, view the HTML 4.01 Strict document type definition (doctype) at http://www.w3.org/TR/html4/strict.dtd and note the following lines:
The HTML 4.01 specification includes additional
syntactic constraints that cannot be expressed within
the DTDs.
So I would say that it is probably not a CFL due to those features (although it technically it doesn't disprove the hypothesis that there is some possible PDA that accepts HTML 4.01, it does prevent the argument that SGML is a CFL therefore HTML is a CFL).
HTML5 flip-flops, abandoning any implied conformance to SGML, but is presumably describable by a CFG. However it will still provide best-effort parsing not based on a cfg, so IMO the current situation (i.e. language specification is defined formally, with invalid strings still being accepted, parsed and rendered in a best effort fashion) in this regard is unlikely to change drastically for a long, long, long time.
HTML5 is different from previous HTML versions in that it strictly defines the parsing behaviour of code that isn't completely correct. Pre-HTML5 parsers vary and each do their best to 'guess' the intention of the code author.