Knowledge representation / Semantic annotation / structured data / linked data on the web

From Helpful
Jump to navigation Jump to search

Generic, not related to library metadata



This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

A Compact URI (CURIE) amounts to a way way to abbreviate a URL in a context - usually to abbreviate many.

It's seen more around XML and XHTML, because they're conceptualized from XML namespaces, though could be used elsewhere fairly easily.

However, they are only parsed by CURIE-aware things, which isn't many(verify).


<html xmlns:wikipedia="">
      <p>Find out more about <a href="[wikipedia:Biome]">biomes</a>.</p>

It is reminischent of a <base> as defined by HTML

but bases are explicit, and has some more path-related rules

It ends up looking like a URN

but you can't really assume the prefix is fixed, as it is in URNs
also, a CURIE expands into URL/URI, while URN is a and stays a string that just happens to be an identifier

See also:


Microformats add semantic markers to HTML.

Emerged at the time of HTML4, and (probably mainly for validation reasons) chose to reuse existing attributes - seemingly mostly class and rel.

For example, showing personal information in HTML and also telling a potential microformat parser what's what according to hCard:

<ul class="vcard">
  <li class="fn">Joe Doe</li>
  <li class="org">The Example Company</li>
  <li class="tel">604-555-1234</li>
  <li><a class="url" href=""></a></li>

See also:


Microdata marks up HTML with the data it is also displaying, e.g.

<div itemscope>
  <p>My name is <span itemprop="name">Neil</span>.</p>
  <p>My band is called <span itemprop="band">Four Parts Water</span>.</p>
  <p>I am <span itemprop="nationality">British</span>.</p>

...yes, it serves similar goals to microformats.

Microdata seems explained as a slightly-more-expressive successor, in that...

Microformats reuse existing parts of HTML4 (mostly class and rel), whereas microdata extends HTML5 with specific custom attributes (e.g. itemscope, itemtype, itemprop).
Also, microformats have sort of a fixed existing set, while microdata points at 'use any thing', allowing community extension.

(side note: that places that sanitize user-sourced HTML are more likely to remove microdata than microformats, due to unknown attributes)

See also:


This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Linked data idea, with keys according to, which happens to be embedded in a page as JSON. (Not to be confused with LDJSON / JSONL / NDJSON, which are serialization formats)

Consider the recipe example from here :

 <script type="application/ld+json">
      "@context": "",
      "@type": "Recipe",
      "name": "Party Coffee Cake",
      "author": {
        "@type": "Person",
        "name": "Mary Stone"
      "datePublished": "2018-03-10",
      "description": "This coffee cake is awesome and perfect for parties.",
      "prepTime": "PT20M"

It's a machine-parseable form of the page's main content, assuming that main content is relatively bite-sized.

Seems to be developed for and targeted primarily at web crawlers.

Yes, this omits the actually useful sections like "ingredient", "yield", "instructions"

Maybe that was just for brevity, or maybe google mostly just cares that you indicate the type of page.

So this sometimes feels more SEO-adjacent (also consider statements like "All annotated information must be on the page; adding information that is not on the page will likely not show in search results and is against Google guidelines") than about structured or linked data.

Yet due to the varied existing schemas you can code a lot of nontrivial things, that you could later extract again.

See also:

Arguably primarily a way to get away from that doing the same in XML.

Ontologies and knowledge representation


RDF triples stored in XML

See also:

Embedded RDF (eRDF)

Embedded RDF (eRDF) places RDF inside HTML.

It was apparently inspired by microformats.

It seems effectively obsolete, as people seem to prefer things like RDFa, Microdata, JSON-LD.

See also:

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

RDFa describes when you express (what you could consider) RDF embedded within HTML attributes (hence the a):

Say, when you have

 <h2>My page title</h2>

You might make that:

 <h2 property="">My page title</h2>

...but you probably want to look at full examples.

Attributes you can use are:

  • property - specifying a property for the content of an element or the partner resource
  • about - when you e.g. have a div describing a resource, this points to the actual resource (URI or CURIE)
  • rel, rev - relationships and reverse relationships with another source
  • typeof - RDF type(s) of the subject or the partner resource
  • src, href, resource - partner resources
  • content - attribute that overrides the content of the element when using the property attribute
  • datatype - attribute that specifies the datatype of text specified for use with the property attribute

RDFa Lite

RDFa Lite intends to be simpler subset of RDFa that allows most things people want to do, and be easier to deal with

  • property
  • vocab
  • resource
  • typeof
  • prefix

Notation3 (Notation 3, N3), Turtle, N-Triples
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Assuming you consider RDF XML the full form, then N3 (a.k.a. Notation3), Turtle, and N-triples can be considered the non-XML shorthands.

They are also closely related:

  • N-triples is equivalent to RDF
  • N3 can code RDF, and has some additional options
file extensions used: n3
  • Turtle is a subset of N3 (also in the sense that Turtle examples are valid N3)
file extensions used: ttl

N-triples is meant to be simpler than N3 and turtle (to read, write, parse), though it lacks some features that it could have had (like CURIE).

See also:


N-Triples plus optional context value


Yet another RDF serialization(verify).

This one an extension of turtle that intends to be ?

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

SKOS is a data model that helps with controlled vocabulary, e.g. taxonomies, and also vocabularies, thesauri, subject headings.

Note that it is only the model for a knowledge representation language to use, and is not a knowledge representations language itself.

That is, it describes classes and properties, but does not assert that objects have them.

Its intent seems to be interoperability, to have a shared basis for modelling done in a semantic-web context, ...instead of each rolling their own (as you could with OWL properties and classes, and RDFS),

You could call it a linked open vocabulary - though note those vary wildly in how widely applicable they are

SKOS's model is itself defined as as an ontology that is expressed in OWL ontology, but that's a bit of a technicality.


Web Ontology Language (OWL) is a family of languages for ontologies

Isn't there real overlap between SKOS, OWL, and RDFS?
More potentially relevant standards

BS 8723

ISO 5964

ISO 2788 - Guidelines for the establishment and development of monolingual thesauri

ISO 25964 - international standard for thesauri and interoperability with other vocabularies[1]

apparently came from (and based on) BS 8723, ISO 2788?

More specific-purpose


See also:


Facebook's Open Graph protocol lets you describe your page, and controls e.g. how sites like how it appears when linked from Facebook, Twitter, and the like

So is arguably structured data. But arguably used largely as an SEO thing and/or just for a nicer preview of links.

More library geared


FRBR ('Functional Requirements for Bibliographic Records'): refers to a model of semantic interrelations between works, realizations, items, responsible entities, and others.

It is focused on bibliographic information, and meant to automate meaningful operations on it.

...though not all types of information found in libraries fits well into FRBR, which probably leads to some creative of the model, that may be incompatible with other such creative use.

There are also limits to applying it to existing information, as various relations are hard to extract exactly and authoritatively. Practice shows that automatically dealing with even just sets of works can be quite a bit of work to do accurately.

People may use the term FRBR loosely, as

a reference to services built on this (e.g. 'we have a a variant of that book you may be interested in')
or the idea or specific datasets (e.g. LibraryThing's) of mappings between a particular book as a work, and various realizations (e.g. revisions)
for some other types of semantic cross-relations.

Group 1 means to refer to the products of intellectual or artistic endeavour:

  • A Work, a distinct intellectual or artistic creation.
  • An Expression, refers to unique intellectual/artistic form present in a realization of a work.
  • A Manifestation is the physical embodiment of an expression.
  • An Item is a single concrete manifestation. (an exemplar of a manifestation)

An example using books:

  • a book someone writes is a work
it's clearly a distinct creation from all other books
  • ...which starts off with just one expression, the original original text
but revisions of the text may be considered distinct expressions
  • are different manifestations - physically clearly different, but the same expression
e.g. a paperback and hardcover variations,
  • each physical book is an item (many items of the same manifestations exists)

Group 2 deals with the custodianship of Group 1 entities, mainly:

  • Persons
  • Corporate bodies

Group 3 deals with subject/event/place relations for Group 1 and 2

  • Concepts
  • Objects
  • Events
  • Places

Further notes:

  • Various bibliographical identifiers implicitly do some some FRBRization. For example, XISBN can be seen as a manifestation identifier.


COinS (ContextObjects in Spans) describes how to embed OpenURL-style citation data in HTML.

It's functionally similar to microformats.

It allows browser plugins to do things including:

  • link you to full-text via your own institution's OpenURL resolver (e.g. using OpenURL Referrer)

See also:

Persistent and open identifiers


DOI (Digital Object Identifier) is a specific standard (syntax is defined in ANSI/NISO Z39.84 [2]) meant to identify pieces of intellectual property, mostly journal articles, research reports, data sets, and official publications.

In a DOI code, for example 10.1000/abc...

  • the 10 designates a DOI
DOI is technically just one implementation of the CNRI Handle system
  • The rest of the code before the slash is the DOI registrant prefix, 1000 in the example above.
You can buy such a prefix from a Registration Agency (or possibly an experimental one from the International DOI Foundation(verify).
  • ...followed by by item identifiers assigned by that registrant. Can be anything.
The combination will always be unique, as the the registrant prefix acts as a namespace)

The combination is like an URN in that it identifies, but does not locate.

You need a DOI resolver to look it up to what it refers to, which gets you to the actual content it points to (usually a landing page first).

This may amount to a search engine, but since these are unique identifiers can give more precise answers.

See also:


ORCID is a persistent identifier for individual researchers, that considers that identities are more unique than names, and that e.g. names themselves can change.

See also:

Older / unsorted

Some theory

Digital - Ontologies, semantic web stuff

Note that some of this is glorified metadata, so see also (Library) metadata notes



This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

An RDF-querying language that wants to look vaguely like SQL.

Has roughly four query types:

  • SELECT - fetches values as they are stored, in table form
  • CONSTRUCT - extract and transform into valid RDF
  • ASK query - ask a yes/no question
  • DESCRIBE - doesn't fetch resources, but describes them in a way that the database maintainer rather than you decides (verify) (which might actually just be a fetch sometimes?(verify))

The wikipedia example for SELECT

PREFIX foaf: <>
SELECT ?name 
    ?person  a          foaf:Person .
    ?person  foaf:name  ?name .
    ?person  foaf:mbox  ?email .

...though depending on how complex, the more you need to know details know the underlying data model (at least look up its constants).

For example, here is a query towards EUR-Lex (you can try it here)

PREFIX cdm: <>
PREFIX annot: <>
PREFIX skos:<>
PREFIX dc:<>
PREFIX xsd:<>
PREFIX rdf:<>
PREFIX owl:<>
select distinct ?work ?type ?celex ?date ?force 
    ?work cdm:work_has_resource-type ?type. 
    FILTER not exists{?work cdm:work_has_resource-type <>
OPTIONAL { ?work cdm:resource_legal_id_celex ?celex. } 
OPTIONAL { ?work cdm:work_date_document      ?date.  } 
OPTIONAL { ?work cdm:resource_legal_in-force ?force. } 
FILTER not exists{?work cdm:do_not_index "true"^^<>}. }


  • all namespaces except the first are unused here
  • Amounts to
    • get all things of type JUDG,
    • except if marked do_not_index,
    • and add fields 'type', 'work', 'celex' 'date' and 'force' if they're there
    • OPTIONAL amounts to "add field if it's there, but don't require it"
stripping it of OPTIONAL { } means only solutions with values will be returned


  • GRDDL (Gleaning Resource Descriptions from Dialects of Languages) is a markup language that to extract RDF from XML, such as XHTML, microformat data in XHTML, and such. [3] [4]

  • SKOS [Simple Knowledge Organization System] [6] [7]
  • SIOC [Semantically-Interlinked Online Communities] [8]
  • 'Common Vocabularies' (and vocabulary mapping) refer to settling things between systems so that they can make inferences more easily [9]
  • Semantic Annotation
  • Rules, specifically in the sens used e.g. in...
  • RuleML [10]
  • Rule Interchange Format (RIF) [11]
  • Semantic Web Rule Language (SWRL) (is OWL+RuleML)

And also various document/item metadata formats, in this context most often

  • Dublin Core
  • DOAP (Description Of A Project) [12]
  • Internet Content Description Language


  • Ontology editors
    • Protégé
    • GATE
    • KAON
    • Hozo

See also