View source for Knowledge representation / Semantic annotation / structured data / linked data on the web

{{#addbodyclass:tag_tech}}
{{#addbodyclass:tag_data}}
{{Library related}}

<!--

Which this is in itself a much wider topic, with many unrelated applications,
semantic content has varied potential uses around research and libraries
* augment search
* extract citations
* find related things / build recommenders

-->


===Generic, not related to library metadata===
<!--
The choice of which to use is probably mostly dependent on what specific search engines or user tools you expect.

For example, [https://developers.google.com/search/docs/advanced/structured-data/intro-structured-data?visit_id=637831185331555274-2012705883&hl=en&rd=1
 google seems understand microdata, microformats and RDFa].

http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/
-->


====URN====
{{stub}}

Many know know [[URL]]s, which ''locate'' a resource. 
: URLs answer ''where''.


[[URN]] answers ''what'', and only what

For example, you might say {{inlinecode|isbn:0898156122}} is an URN - a namespace to name a ''kind'', and a value to be interpreted in that namspace.
: These namespaces are [https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml registered with IANA]
: though there's nothing really keeping you from creating [[ad-hoc standards]]

(URI basically encompasses both, so roughly means 'URL ''or'' URN'.)


URNs are, by themselves, a little too generic, in that there isn't a clear way to say "this is an URN you should do something with" in a generic information embedding way, without e.g. putting it on a contextually specific lookup URL.

URNs are, potentially, a way to drop some basic type-value items into HTML,
but since there is no standard way to resolve these, 
this primarily has uses in relatively niche uses, 
where multiple sides/apps have added some agreements on how to ''use'' them.

====CURIE====

{{stub}}

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}}.


Consider:
<syntaxhighlight lang="html">
<html xmlns:wikipedia="http://en.wikipedia.org/wiki/">
  <head></head>
  <body>
      <p>Find out more about <a href="[wikipedia:Biome]">biomes</a>.</p>
  </body>
</html>
</code>
</syntaxhighlight>


It is reminischent of a [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base &lt;base&gt;] as defined by HTML, but HTML bases are explicitly defined, and have 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:
* https://en.wikipedia.org/wiki/CURIE
* https://www.w3.org/TR/curie/

====Microformats====
'''Microformats''' add semantic markers to HTML. 

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


For example, showing personal information in HTML and also telling a potential microformat parser what's what according to [https://en.wikipedia.org/wiki/HCard hCard]:
<syntaxhighlight lang="html">
<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="http://example.com/">http://example.com/</a></li>
</ul>
</syntaxhighlight >

<!--
Lets you embed and extract things like event details, contact information, up to things like products, reviews, recipes. 

Microformats are great for a few specific uses, 
but were never very big, arguably because their goal was partly not clear, partly just specific and niche and the list was never long.

They also don't solve something for end users that doesn't require specialized tools to work,
so it's arguably largely of an SEO thing - which is arguably just as true for microdata and JSON-LD.
-->

See also:
* http://en.wikipedia.org/wiki/Microformats
* http://microformats.org/

====Microdata====

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

<syntaxhighlight lang="html">
<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>
</div>
</syntaxhighlight >


...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 [http://microformats.org/wiki/Main_Page#Specifications sort of a fixed existing set], while microdata points at 'use any [https://schema.org/docs/schemas.html schema.org] thing', allowing [https://schema.org/docs/extension.html community extension].


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

See also:
* https://html.spec.whatwg.org/multipage/#toc-microdata
* https://en.wikipedia.org/wiki/Microdata_(HTML)

====JSON-LD====
{{stub}}

Linked data idea, with keys according to schema.org, which happens to be embedded in a page as JSON.
{{comment|(Not to be confused with [[LDJSON]] / [[JSONL]] / [[NDJSON]], which are serialization formats)}}


Consider the [https://developers.google.com/search/docs/advanced/structured-data/intro-structured-data?visit_id=637831185331555274-2012705883&hl=en&rd=1 recipe example from here] :
<syntaxhighlight lang="html">
 <script type="application/ld+json">
    {
      "@context": "https://schema.org/",
      "@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"
    }
 </script>
</syntaxhighlight >

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",
which seems to indicate this was not aimed at structured data, but at crawler just caring about the ''type'' of page.

So this feels more SEO-adjacent ''metadata'' than about structured or linked ''data'' {{comment|(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")}}. 

Yet it's an open-ish mechanism, 
and due to the varied existing schemas you ''can'' code a lot of nontrivial things, that you could later extract again.


See also:
* https://en.wikipedia.org/wiki/JSON-LD

* http://json-ld.org/spec/latest/json-ld/

* https://moz.com/blog/json-ld-for-beginners

* https://developers.google.com/search/docs/advanced/structured-data

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


<!--
[https://jsonld.com/person/ Person example]
-->

====Ontologies and knowledge representation====

<!--
There's some abstract philosophical that we could get into, 
like that a symbol, a concept, and a referent are not the same.

And in some applications this gets very relevant to even the way it's set up.

Yet you could take a more practical approach and just start structuring things and presenting the result,
and later seeing whether it could use improvements

-->


=====RDF=====
<!--
{{stub}}
Refers to a set of W3 standards dealing with semantic data storage and modelling, but mostly specifically XML documents used regularly used to transfer semantic information.


Related:

* RDFS refers to schemas for RDF.

* eRDF, Embedded RDF (in HTML)

* RDFa (RDF in attributes) [http://en.wikipedia.org/wiki/RDFa]


-->

======RDFS======

RDF Schema

https://en.wikipedia.org/wiki/RDF_Schema

======Trix======

RDF triples stored in XML

See also:
* https://en.wikipedia.org/wiki/TriX_(serialization_format)
* https://www.w3.org/2004/03/trix/


======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:
* https://en.wikipedia.org/wiki/Embedded_RDF


======RDFa======
{{stub}}

'''RDFa''' describes when you express RDF-like content within HTML '''a'''ttributes (hence the a):


This is still a flexible concept.

If you ''start'' with HTML and want to mark what its parts are better, you might start with 
<syntaxhighlight lang="html">
 <h2>My page title</h2>
</syntaxhighlight >
and make that:
<syntaxhighlight lang="html">
 <h2 property="http://purl.org/dc/terms/title">My page title</h2>
</syntaxhighlight >
...but you probably want to look at [https://en.wikipedia.org/wiki/RDFa#Examples full examples].


One real-world example I found was EUR-Lex encoding a bunch of metadata in their HTML pages, e.g. [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A31965L0001 31965L0001] contains 200+ lines like:
<syntaxhighlight lang="html">
<meta about="http://data.europa.eu/eli/dir/1965/1/oj" typeof="eli:LegalResource"/>
<meta about="http://data.europa.eu/eli/dir/1965/1/oj" property="eli:uri_schema" resource="http://data.europa.eu/eli/%7Btypedoc%7D/%7Byear%7D/%7Bnatural_number%7D/oj"/>
<meta about="http://data.europa.eu/eli/dir/1965/1/oj" content="31965L0001" lang="" property="eli:id_local"/>
<meta about="http://data.europa.eu/eli/dir/1965/1/oj" property="eli:type_document" resource="http://publications.europa.eu/resource/authority/resource-type/DIR"/>
<meta about="http://data.europa.eu/eli/dir/1965/1/oj" property="eli:passed_by" resource="http://publications.europa.eu/resource/authority/corporate-body/CONSIL"/>
</syntaxhighlight>
..which seems to come more from a "We had RDF triples and put them in here for you to parse" angle.


Attributes you can use include:
* '''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


http://en.wikipedia.org/wiki/RDFa

https://www.w3.org/TR/rdfa-core/

======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'''

https://www.w3.org/TR/rdfa-lite/#introduction

https://www.w3.org/TR/rdfa-lite/

======Notation3 (Notation 3, N3), Turtle, N-Triples======
{{stub}}

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    {{comment|(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]]).

<!--
Define prefix:
 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .



-->

See also:
* http://en.wikipedia.org/wiki/Turtle_(syntax)
* http://en.wikipedia.org/wiki/Notation_3
* http://en.wikipedia.org/wiki/N-Triples

======N-Quads======

N-Triples plus optional context value


======TriG======

Yet another RDF serialization{{verify}}.

This one an extension of turtle <!--that intends to be ?-->


https://www.w3.org/TR/2014/REC-trig-20140225/#sec-trig-intro

=====SKOS=====
{{stub}}

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
https://lov.linkeddata.es/dataset/lov/


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



https://en.wikipedia.org/wiki/Simple_Knowledge_Organization_System

https://www.w3.org/TR/2009/REC-skos-reference-20090818/


=====OWL=====

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


https://en.wikipedia.org/wiki/Web_Ontology_Language

=====Isn't there real overlap between SKOS, OWL, and RDFS?=====
<!--

Yes.

Welcome to a world of abstract meta-concept confusion, 
to each thing within that world having an interesting history,
and (somewhat ironically) to starting at sentences and wondering what they even mean.


For example, SKOS focuses on classes and properties, and interdependencies between them. 
This makes it 
: ''more'' than just a controlled vocabulary (because of the relations)
: but ''less'' than a knowledge representation language, or useful for inference (e.g. because your modeling is mostly limited to hierarchy)


If you need those things, look towards other acronyms, including but certainly not limited to OWL and RDFS.

In a document that ''does'' do those additional things, it might still be very useful to then also ''include'' a SKOS definition as a "...and here's the vocabulary we're working within," and use concepts in it.

For example, RDF triplets may, (after inclusion of the SKOS model) say things like
 rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:altLabel "adoration"@en ;
  skos:broader <B> ;
  skos:inScheme <S> .


...Though this may not be necessary as other things may have vocabulary covered - or not.
This depends on what you're combining - RDF doesn't, other things do.


'''Doesn't that mean SKOS overlaps with OWL properties and classes, and RDFS?'''

Yes. 

And it needs to be more clearly stated what they share and do not share (TODO)


-->

=====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[https://www.niso.org/schemas/iso25964]
: apparently came from (and based on) BS 8723, ISO 2788?

====More specific-purpose====
=====FOAF=====
<!--

Friend of a Friend

Simple RDF-based structure expressing basic public information about persons, including other persons that they know.

There are related declarations of communities (SIOC), and also of more specific things like projects (DOAP), careers (DOAC).

-->
See also:
* http://en.wikipedia.org/wiki/FOAF_(software)

=====OGP=====

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.


https://ogp.me/

===More library geared===

====FRBR====

'''FRBR''' ([http://en.wikipedia.org/wiki/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.



<!--
One has to wonder whether it is just something hip to play with, 
though it clearly has merits, 
and has usefully driven people to think about 
normalized forms of data,
collocation-based browsing of materials,
and more.
-->


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)

<!--
In the case of books, a manifestation correlates strongly with 'something that gets an unique ISBN'
-->

<!--

One possible problem cases include translations, annotated editions and such. 

These can be considered a different expression of the same work, or a different work, which you can argue depends on the specific case - translations that involve/require involved creativity may well be considered a new work.

These sort of cases can break FRBR's potential simplicity (which is not altogether surprising, as it is a fairly simple model of a fuzzy domain).



Its model makes explicit something that similar systems also tend to do, that is to separate '''work''' from '''expression''' from '''manifestation''' from '''item'''.

To take wikipedia's example, 

* A '''work''' is distinct intellectual/artistic creation)
: e.g. "Beethoven's Ninth" is a work

* A expression is a -- any -- realized form of the work
: e.g. Each draft Beethoven wrote down - specifically the the music represented on it

* A manifestation is all the physical objects that bear the same characteristics
: arguably both the specific paper he wrote each draft on, and any particular performance of that music

* An item
: say, a library may have multiple copies of any once performance


The separation is useful, but there are also issues.

Say a composer wants to tweak something for their specific orchestra. 
: Is this merely a distinct manifestation (differs only in the physical performance)
: Is this a distinct expression (that physical performace is easy enough to annotate. Does it change the music or not)
: Is this a distinct work ("Beethoven's Ninth varied is easier to play for some")

-->


'''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====


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:
* extract citations (e.g. using [http://www.zotero.org/ Zotero], [https://en.wikipedia.org/wiki/Citavi Citavi], others)

* link you to full-text via your own institution's OpenURL resolver (e.g. using [https://addons.mozilla.org/en-US/firefox/addon/4150 OpenURL Referrer])


See also:
* http://ocoins.info/

* https://www.univie.ac.at/elib/index.php?title=COinS_Microfromat_Bibliographic_Metadata_for_Embedding_in_HTML

===Persistent and open identifiers===

<!--
{{stub}}

Identifiers are by themselves only at being locally unique. Without further thought,
* identifiers may be ambiguous between systems
* may only clearly exist within the one system that uses them,
* references may stop being useful if that system stops,
* you may not know when they may be removed
* you may not know when if they may get reused
...and further details.


A persistent identifier (PI or PID) means is a (unique) identifier references, with added promise such as that
* these are meaningful outside the originating system
:: meaning you can more easily reference resources unambiguously,
:: implementation-wise often implying some way to administer them (uniquely) from one or more places
* will probably resolve to something useful for a good amount of time
:: typically metadata
:: often content/data


Depending on the type of things you identify, it makes it easier to not only reference resources, and find metadata and data belonging to it, but also credit people, institutions, funding, unambiguously mention the intruments you used.

This makes it ''easier'' to 
provide some types of scientific transparency, 
more fine grained metadata to finding similar research, 
and more.




Ideally, they 
* are universally unique

* clear

* long lived

* well known - e.g. DOI has become more useful through being well known



PIDs are not hard to do. At a technical level they are almost trivial.

Most of the work lies in the origin respository declaring their intent
and committing to the idea, in that universality and longevity sort of depend on it.




You can get something close enough, combining
* a globally unique reference to the repository
* a repository-specific identifier

...but that's a moving-the-problem-around with various impractical drawbacks.


-->

https://en.wikipedia.org/wiki/Persistent_identifier


====DOI====

DOI (Digital Object Identifier) is a specific standard (syntax is defined in ANSI/NISO Z39.84 [http://www.google.com/search?q=%22Z39.84%22+%22Syntax+for+the+Digital+Object+Identifier%22]) meant to identify pieces of intellectual property, mostly journal articles, research reports, data sets, and official publications.


In a DOI code, for example <tt>10.1000/abc</tt>...

* the 10 designates a DOI
:: DOI is technically just one implementation of the [https://en.wikipedia.org/wiki/Handle_System 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 [http://www.doi.org/registration_agencies.html 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.

<!--
A search tool used at a specific institution might present a DOI a link, with an URL putting that looks that DOI up as that specific institution. The idea is that you could look it up anywhere else.
-->
 


See also:
* http://en.wikipedia.org/wiki/Digital_object_identifier

====ORCID====

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:
* https://en.wikipedia.org/wiki/ORCID

* https://orcid.org/

=Older / unsorted=


==Some theory==
<!--
(often overlapping with linguistics)


Frame semantics

http://en.wikipedia.org/wiki/Frame_semantics_(linguistics)


Sentence diagrams

http://en.wikipedia.org/wiki/Sentence_diagram


See also [[metadata]].


Problems with current knowledge representation include
* that much of it is very boolean - there or not, with no value.
* that bias seems to be away from the structures/pragmatics used in human consideration (which seems to not be studied enough)



-->






<!--
==Formal knowledge representation==
Things are often stored in one of various (re)implementations of a graph structure, designed for a specific type of data or metadata.


The "Semantic web" is a relatively vague idea that mostly calls for well-annotated / well-defined data placed in a web context, which allows occasionally automatic or semi-automatic processing, referencing, verification, and data extraction.

A few results are neat, but it has for a considerable part turned out the term that unites most people that are trying to implement such technical semantic smartness; very few ideas are settled thoughout, and even standards are argued about.
-->


==Digital - Ontologies, semantic web stuff==

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


===Query===

====SPARQL====
{{stub}}


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

<syntaxhighlight lang="sql">
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name 
       ?email
WHERE
  {
    ?person  a          foaf:Person .
    ?person  foaf:name  ?name .
    ?person  foaf:mbox  ?email .
  }
</syntaxhighlight>
...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 [https://publications.europa.eu/webapi/rdf/sparql here])
<syntaxhighlight lang="sql">
PREFIX cdm: <http://publications.europa.eu/ontology/cdm#>
PREFIX annot: <http://publications.europa.eu/ontology/annotation#>
PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
PREFIX dc:<http://purl.org/dc/elements/1.1/>
PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl:<http://www.w3.org/2002/07/owl#>
select distinct ?work ?type ?celex ?date ?force 
WHERE {
    ?work cdm:work_has_resource-type ?type. 
    FILTER(?type=<http://publications.europa.eu/resource/authority/resource-type/JUDG>)
    FILTER not exists{?work cdm:work_has_resource-type <http://publications.europa.eu/resource/authority/resource-type/CORRIGENDUM>
}
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"^^<http://www.w3.org/2001/XMLSchema#boolean>}. }
</syntaxhighlight>


Note:
* 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



https://en.wikipedia.org/wiki/SPARQL

===Unsorted===

* 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. [http://www.w3.org/2004/01/rdxh/spec] [http://www.w3.org/2001/sw/grddl-wg/]


* FOAF [http://www.foaf-project.org/]


* SKOS [Simple Knowledge Organization System] [http://www.w3.org/2004/02/skos/] [http://esw.w3.org/topic/SkosDev/DataZone]
* SIOC [Semantically-Interlinked Online Communities] [http://sioc-project.org/]

* 'Common Vocabularies' (and vocabulary mapping) refer to settling things between systems so that they can make inferences more easily [http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies] 

* Semantic Annotation

* Rules, specifically in the sens used e.g. in...
* RuleML [http://www.ruleml.org/]
* Rule Interchange Format (RIF) [http://www.w3.org/2005/rules/wiki/RIF_Working_Group]
* 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) [http://trac.usefulinc.com/doap]

* Internet Content Description Language


Software
* Ontology editors
** Protégé
** GATE
** KAON
** Hozo

* Reasoners - http://en.wikipedia.org/wiki/Semantic_reasoner




http://en.wikipedia.org/wiki/Template:Semantic_Web

===See also===
* http://www.ukoln.ac.uk/repositories/digirep/index/Repositories_Research


* http://en.wikipedia.org/wiki/Semantic_web




<!--
==Unsorted==
Mind maps, concept maps, etc.
-->
[[Category:Library and research data]]