Comment by gambler | Hacker News Reader

Comment by gambler | Hacker News Reader

RSS/Atom is being slowly killed. XHTML was replaced by a pile or junk that can only be parsed by a single parser. HTML in general became a rendering layer for executable JavaScript. After years of doing integrations, I've seen one(!) HATEAOS web service and it's being replaced by GraphQL right now.

I like the idea of having semantic content, but it is suffocating under the weight of all the overcomplicated designed-by-committee abstractions and formats. In fact, the real web that we're using is becoming less and less semantic every year.

I wish someone re-standardized XML without all the complicated edge case garbage and with better handling of namespaces. So it would actually get used for documents again. JSON is not a good document format, and it seems everyone is busy re-inventing XML in JSON right now.

Let's say I want to define my own concept and put it on a web page. Is there even an "official" way to do it right now, without namespaces in HTML5? Theoretical example:

    <html>
    <head>
    <concept tag="computer-game" guid="c1a3e0cb-5872-4e5a-8dce-b8afc00772db" />
    <concept attribute="year-published" guid="ba073188-8bd6-47a7-9065-eb55c4a8b908" />
    </head>

    <body>
        <computer-game year-published="1993">Doom</computer-game>
    </body>
    </html>

Simple, isn't it? I'm not aware of anything of this sort.

To answer your question, you can use HTML+RDFa to annotate any element with semantic info, or simply use meta-links (in the HTML head) for per-page metadata.

W3C's semantic web is a lost cause, though, as is XHTML. I don't know why the paper speaks about "the first 20 years", as there's been zero activity for years and I think the semweb charters have been closed years ago.

If you're interested in document engineering based on real and practical standards, I'd suggest looking into ISO SGML (superset of XML and HTML) and maybe ISO Topic Maps (with Tolog/ISO Prolog as query language).

> Let's say I want to define my own concept and put it on a web page. Is there even an "official" way to do it right now

What's wrong with Microdata? As in https://en.wikipedia.org/wiki/Microdata_(HTML) It can interoperate with RDF and JSON-LD.

First time I hear about it. Let's see.

It seems to aim at roughly the same problem, but god, they've managed to design something even uglier and more verbose than XML namespaces. Still requires to use valid URLs instead of GUIds. Still forces you to use external names in your markup. Sigh.

One hard limitation I see is that unlike namespaces it doesn't deal with HTML attributes, so you can't just annotate the same tag with unrelated semantics.

It also makes assumptions about document structure (item properties are nested inside an item). Semantics and structure should not be complected. This will create innumerable issues when doing logic in code or writing CSS queries.

Why does this have to be so ugly and complicated? All we really need is a way to associate data with globally unique identifiers. This gives us semantics. A single layer of indirection (mapping GUIDs to local names of your choice) would allow us to be concise and descriptive in our markup, while avoiding naming conflicts.

No matter how much W3C hates it, people are extending HTML with custom tags and attributes. (ng-whatever, for example.) Having no support for providing semantics for such things is pretty ridiculous.

> Still requires to use valid URLs instead of GUIds.

Not sure why you would want to do this, but AIUI you can use any URI for a namespace (not just URL), including a UUID via the `urn:uuid:c1a3e0cb-5872-4e5a-8dce-b8afc00772db` syntax.

You can but most of the time, especially with Linked Data, an URL is required. And sometime even a dereferencable one. So you have this weird situation where you never really know if an URL is "semantic" (just a string actually) or can be accessed. Also having a dependency on the DNS system is a bad idea in my opinion. It's really clear when you read 2 years old semantic web paper and every link is broken.

I agree with gambler that GUID + local names is a better solution, and I use that in my research.

I’m thinking IPLD is looking like a great fix for that particular issue.

https://ipld.io

It seems rather overengineered to me. IETF and W3C standards do support the general content-addressing, "naming things with hashes" use case via the existing ni:// (Named Information) URI schema (RFC6920).

It's possible to define custom HTML tag in javascript, but I don't think that is what you want.

https://developer.mozilla.org/en-US/docs/Web/API/CustomEleme...

Indeed. It could be useful for rendering custom tags, but the problem with semantic content is that there needs to be an entry point somewhere.

No matter how I think about it, it seems that at some level there always needs to be a way to say "this piece of data is officially ba073188-8bd6-47a7-9065-eb55c4a8b908 (year of publishing)". Which means that whenever you see another ba073188-8bd6-47a7-9065-eb55c4a8b908, you and all your tools know the data refers to the same kind of thing.

Everything else can be bootstrapped.

XML solved this through namespaces + URLs. IMO, it was a cludgy and inelegant solution with weird syntax and unnecessary levels of abstraction, but at least it was something.

I've come up with a new notation Mark (http://marknotation.org/), to address some of issues faced with JSON and XML.

It keeps the simplicity of JSON, and is able to support mixed content at the same time.

At the moment, it leaves out namespace to the application.

Your sample in Mark would look like:

  {html
    {head
      {concept tag:computer-game guid:"c1a3e0cb-5872-4e5a-8dce-b8afc00772db"}
      {concept attribute:year-published guid:"ba073188-8bd6-47a7-9065-eb55c4a8b908"}
    }
    {body
      {computer-game year-published:1993 "Doom"}
    }
  }

Looks pretty good. Not sure how I feel about including JSON as type of embedded content, though.

I've used something vaguely similar in the distant past, but it was strictly internal for my hobby projects and mostly resembled lisp with square brackets. It was way more primitive, but the parser (lexer, really) fit into two blocks of code. All the fancy stuff was done within DOM.

Reply on news.ycombinator.com