This is slightly more complicated than the other types of resource, as the thing at the article URI isn't a description of the article, it *is* the article.
To handle this, the description of the article is separated from the article itself. This is to enable the metadata about the article to be under a different licence from the article proper, and to enable RES to be able to index the location of, as well as metadata about, the article.
Base URI
Item source
| ItemPath | Templates |
|---|
| /sitecore/content/Home/Discovering Literature/Articles |
BL_Global_Page_Article |
Item definition
This is the same as outlined in Common Definitions except for the omission of dct:hasFormat for base URI + '/'
| Property | Value Source | Sample Value | Notes |
|---|
| dct:hasFormat |
base URI + '/' |
|
Not present for an article |
#article
The abstract article which is described by the metadata (the base, non-hash URI) and which is primarily rendered as the article content of the HTML page at the original URL.
Note that multiple types are specified to make the resource more readily visible in the index.
Item definition
Base URI + '/'
The following is present in addition to the triples laid out in Common Definitions
| Property |
Value Source |
Sample Value |
Notes |
rdf:type
|
Fixed
|
dcmit:Text
|
|
| rdf:type |
Fixed |
foaf:Document |
|
dct:license
|
Fixed |
http://www.bl.uk/aboutus/terms/copyright/ |
License on the HTML representation of the article. For the purposes of this exercise, this can match the license on the #article resource, as the #article's primary representation is as HTML. But note that there could theoretically be a situation where the content of a web page (i.e. the whole web page) is licensed differently from the content of an article (i.e. the #article resource) displayed on that web page. In this case, the licence here would be the licence of the whole web page, not the licence of the #article resource.
|
| dct:title |
Dynamic |
"'An Introduction to The War of the Worlds' as HTML"@en
|
Title of the article - Note: This differs from Common Definitions |
@prefix bibo: <http://purl.org/ontology/bibo/> .
@prefix bl: <http://www.bl.uk/ns#> .
@prefix cc: <http://creativecommons.org/ns#> .
@prefix dcmit: <http://purl.org/dc/dcmitype/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix formats: <http://www.w3.org/ns/formats/> .
@prefix frbr: <http://purl.org/vocab/frbr/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix void: <http://rdfs.org/ns/void#> .
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds>
a foaf:Document, dcmit:Text, formats:Turtle ;
dct:title "Description of 'An Introduction to The War of the Worlds' as Turtle"@en ;
foaf:primaryTopic <http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds#article> ;
cc:license <http://creativecommons.org/publicdomain/zero/1.0/> ;
dct:format <http://purl.org/NET/mediatypes/text/turtle> ;
void:inDataset <http://www.bl.uk/romantics-and-victorians/articles/#dataset> .
<http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds#article>
a foaf:Document, schema:Article, bibo:Article, frbr:Work ;
dct:title "An Introduction to The War of the Worlds"@en ;
dct:creator <http://www.bl.uk/people/experts/iain+sinclair#person> ;
dct:created "2015-12-31T12:57:00"^^xsd:dateTime ;
cc:license <http://www.bl.uk/aboutus/terms/copyright/> ;
bl:relatedWork <http://www.bl.uk/works/the-war-of-the-worlds#work> ;
bl:relatedPerson <http://www.bl.uk/people/h-g-wells#person> ;
bl:relatedCollectionItem <http://www.bl.uk/collection-items/the-great-war-in-england#item> ;
bl:relatedCollectionItem <http://www.bl.uk/collection-items/messages-from-mars#item> ;
rdfs:seeAlso <http://www.bl.uk/works/the-war-of-the-worlds#work> ;
rdfs:seeAlso <http://www.bl.uk/people/h-g-wells#person> ;
rdfs:seeAlso <http://www.bl.uk/collection-items/the-great-war-in-england#item> ;
rdfs:seeAlso <http://www.bl.uk/collection-items/messages-from-mars#item> ;
wdrs:describedBy <http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds> ;
foaf:page <http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds/> .
<http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds/>
a foaf:Document ;
dct:format <http://purl.org/NET/mediatypes/text/html> ;
cc:license <http://www.bl.uk/aboutus/terms/copyright/> ;
dct:title "'An Introduction to The War of the Worlds' as HTML"@en .
foaf:Document.
Comments (9)
Elliot Smith said
at 10:00 am on Oct 7, 2016
To make this consistent with Work/Item etc., I would move most of the statements on the non-hash resource (http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds) onto the #article resource (http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds#article). I would reserve the non-hash URI for statements about the metadata: i.e. the foaf:primaryTopic pointing to the # URI, the license for the metadata, author of the metadata (if relevant) etc. The article itself may have different copyright from the metadata about it, so you need the separate hash URI for this abstract "article".
This is something I've spent a bit of time thinking about, and is slightly counter-intuitive, but from what I gather this ensures that RES can index the resource. If the statements about the article are all at the same URI as the article, the copyright on the article is taken to apply to the metadata, too. By putting the abstract concept of "the article" at a hash URI, we can keep metadata about the article at the original URI, with a RES-friendly license.
One way to rationalise this is to think of the web page as being the HTML representation of "the article"; this leaves "the article" (#article) as an abstract "thing" which can have different representations, including HTML, PDF, RDF etc. Using this approach, the web page isn't the same thing as this abstract article, as the web page has headers/footers/side bars/menus which aren't part of the article, only part of its representation as HTML.
Richard Light said
at 11:49 am on Oct 7, 2016
+1 to every Elliot says. :-)
What is the BL namespace? The URL quoted (with double 'http://') doesn't resolve to anything, as far as I can see. This will need to become a real thing if it's to form part of the RDF framework.
It seems to me that the whole framework is too focused on the HTML articles, and not enough on the RDF describing them. For example, the link to H.G. Wells should surely be to the root URL http://www.bl.uk/people/h-g-wells, not to the hash URI for the article about him. Otherwise any navigation around your conceptual framework will bypass the RDF completely, making the exercise largely pointless.
Richard Light said
at 11:50 am on Oct 7, 2016
That should be '+1 to everything', of course. (Pesky wiki won't let me edit comments!)
Elliot Smith said
at 1:01 pm on Oct 7, 2016
The hash URIs (in this schema, and generally in stuff indexed by RES), refer to "things". So http://www.bl.uk/people/h-g-wells#person is a name for the (real-world) person H.G. Wells (ignore for the moment that it is represented by a web resource). In this case, I think it's correct to use http://www.bl.uk/people/h-g-wells#person as the related person, as the article refers to the real-world thing "H.G. Wells".
Using hashes is another solution for the dereferencing of URIs, and is an alternative to using 303s to redirect from a resource URI to a representation of the resource in HTML/RDF. Though, arguably, hash URIs are more confusing.
Because the hash is stripped from the URI when it's resolved on the web, requesting http://www.bl.uk/people/h-g-wells will give you the metadata about the resource (e.g. the copyright on the metadata), as well as a representation of the resource (RDF about the real-world H.G. Wells). This is the pattern suggested in the Acropolis/RES guide: https://bbcarchdev.github.io/inside-acropolis/#document-metadata.
Elliot Smith said
at 1:11 pm on Oct 7, 2016
Though of course it depends on the exact semantics of relatedPerson: are you stating that there is a Person resource on this site which relates to this article (http://www.bl.uk/people/h-g-wells), or that the article is about the foaf:Person (real life) H.G. Wells (http://www.bl.uk/people/h-g-wells#person)?
Elliot Smith said
at 1:33 pm on Oct 7, 2016
The bibliontology type for an Article on the BL website could be specified as follows:
@prefix bibo: http://purl.org/ontology/bibo/ .
<http://www.bl.uk/romantics-and-victorians/articles/an-introduction-to-the-war-of-the-worlds#article> rdf:type bibo:Article .
Note that the subject here is the abstract "article" which is manifested on the site as a web page.
Owen Stephens said
at 12:57 pm on Oct 12, 2016
Possibly could look at using schema.org/Article to describe articles?
Bibo is obviously a specialist vocabulary, but Schema will be more widely referenced and opens up the possibility of using the RDF to generate schema.org as JSON-LD which could then be referenced from the website and indexed by Google et al
Elliot Smith said
at 3:45 pm on Oct 12, 2016
This is a good idea, and I've included an rdf:type schema:Article on the #article resource as a placeholder. There's no reason that additional statements couldn't be added for author etc. from the schema.org vocab. But, for the moment, I wanted to include statements which I know RES indexes and which have a particularly privileged status; and I also stuck to statements which will be readily identified by a consumer of the index.
Elliot Smith said
at 4:02 pm on Oct 12, 2016
I'm not 100% sure that rdfs:seeAlso and bl:related* should point at hash URIs, as these represent real "things", rather than descriptions.
You don't have permission to comment on this page.