We consistently use label/altlabel in lobid-resources and lobid-organisations and, thus, should probably also use it in lobid-authorities...

Currently I always get a maximum of ten results, no matter of what I set the size parameter to (see e.g. http://test.lobid.org/authorities/search?q=academicDegree:*&size=19).

From #1:

We don't want specific name properties like preferredNameForThePlaceOrGeographicName and variantNameForThePlaceOrGeographicName. For all entities, we should just use preferredName and variantName.

This will allow us to query the whole data in a uniform way. (The type is made clear by other means so that we don't need the specific properties.)

Both dumps and updates (via OAI) are available as RDF-XML, so that would be a suitable source format:

http://datendienst.dnb.de/cgi-bin/mabit.pl?userID=opendata&pass=opendata&cmd=login
http://www.dnb.de/DE/Service/DigitaleDienste/OAI/oai_node.html (s. "Formate")

We should test serializing that RDF-XML as compact JSON-LD using the entityfacts context:

http://hub.culturegraph.org/entityfacts/context/v1/entityfacts.jsonld
http://hub.culturegraph.org/entityfacts/118540238

If the result looks good, this might be the format to index in Elasticsearch. We might have to do some preprocessing to make sure the values always have the same type (see footnote 1 in http://blog.lobid.org/2017/06/08/lobid-api-why-how.html about compact JSON-LD serialization in Elasticsearch).

...while they are actually subclasses of "Differentiated Person".

See http://test.lobid.org/authorities/search?q=*

Moving from old lobid-gnd repo, issue by @acka47.

We will use short keys instead of the URIs for classes/types in GND API 2.0. Thus, we will need these keys be defined in the @context. At best, we will generate this (half-)automatically from the GND ontology.

We already did some half-automatic generation of the GND context, see lobid/lodmill#251 & https://gist.github.com/niklasl/2770154#gistcomment-946311.

I once again used Niklas' python tool and created the JSON-LD context. Afterwards a bit of manual post-processing was necessary as well as addition of owl:sameAs and foaf:page and the deletion of deprecated properties and classes. The result can be found at .https://gist.github.com/acka47/98035a3f215c783bdc00.

Leaving this open (and renaming the ticket) until the context is published.

People should get suggestions when typing a search time.

I will provide a label per type in a later comment to this issue.

Currently, it looks like an "edit" button.

Moved here with some adjustments from lobid/lodmill#447.

Example query: "heinsberg"

Facets/possibilities for filtering by secend-level types:

• Person
• Subject Heading
• Place or Geographic Name
• Converence or Event
• Family
• Corporate Body
• Work

(Similar to e.g. https://portal.dnb.de/opac.htm?method=simpleSearch&query=heinsberg)

Clicking a facet should yield filtered search results with sub-facets, e.g.:

Place or Geographic Name:

• Building or Memorial
• Administrative Unit
• Fictive Place
• ...

At some point, we should switch lobid-authorities to public beta:

• Use the beta.lobid.org subdomain for http://test.lobid.org/authorities
• Add "authorities beta" to the main navigation at http://lobid.org

Perhaps we could add a beta label for the issues that need to be solved before we do so.

@acka47 What do you think?

See https://lobid.org/gnd/

• Einträge mit widersprüchlichen Type-Angaben und properties, siehe auch http://lists.dnb.de/pipermail/gnd-ontology/2016-July/000083.html. Beispiele:
  • 2423 Einträge von Typ ConferenceOrEvent mit preferredNameForTheCorporateBody: http://test.lobid.org/authorities/search?q=type:ConferenceOrEvent+AND+preferredNameForTheCorporateBody:*
  • 188 Einträge von Typ CorporateBody mit preferredNameForTheConferenceOrEvent: http://test.lobid.org/authorities/search?q=type:CorporateBody+AND+preferredNameForTheConferenceOrEvent:*
  • 78 Einträge vom Typ DifferentiatedPerson mit preferredNameForTheCorporateBody: http://test.lobid.org/authorities/search?q=type:DifferentiatedPerson+AND+preferredNameForTheCorporateBody:*
  • 93 Einträge vom Typ CorporateBody mit preferredNameForThePerson: http://test.lobid.org/authorities/search?q=type:CorporateBody+AND+preferredNameForThePerson:*
  • 83 Einträge vom Typ PlaceOrGeographicName mit preferredNameForTheCorporateBody: http://test.lobid.org/authorities/search?q=type:PlaceOrGeographicName+AND+preferredNameForTheCorporateBody:*
  • 60 Einträge vom Typ ConferenceOrEvent mit preferredNameForTheSubjectHeading: http://test.lobid.org/authorities/search?q=type:ConferenceOrEvent+AND+preferredNameForTheSubjectHeading:*
  • 9 Einträge von Typ SubjectHeadingSensoStricto mit preferredNameForTheCorporateBody: http://test.lobid.org/authorities/search?q=type:SubjectHeadingSensoStricto+AND+preferredNameForTheCorporateBody:*
• gndo:academicDegree wird sowohl mit URI (z.B. 100095089) als auch mit Strings (z.B. 100072488) benutzt, obwohl im Oktober 2013 angekündigt wurde, dass die Property nur noch als datatype property benutzt werden würde.

E.g. http://lobid.org/gnd/search?q=k%C3%B6ln

Currently, we only allow filtering by first-level types Person, CorporateBody, ConferenceOrEvent, Work, PlaceOrGeographicName, SubjectHeading, Family.

One adjustment should be that the filter section adjusts when clicking on a type: Either the not-clicked first-level types shoud disappear (and the sub-types should be shown, see below) or the not-clicked types should be greyed out.

We should also enable filtering by the subtypes in these two ways:

1. Add a "+" sign to first-level types with sub-typing so that people can klick on it and the sub-types are shown. (E.g. for "Place or Geographic Name" "Building or Memorial", "Administrative Unit", "Fictive Place" etc.)
2. Filtering by a first-level type should yield filtered search results with sub-facets opening up

Documentation: http://www.dnb.de/DE/Service/DigitaleDienste/EntityFacts/entityfacts_node.html

Example of sameAs links for London:

{
  "sameAs":[
    {
      "@id":"http://d-nb.info/gnd/4074335-4/about",
      "collection":{
        "abbr":"DNB",
        "name":"Gemeinsame Normdatei (GND) im Katalog der Deutschen Nationalbibliothek",
        "publisher":"Deutsche Nationalbibliothek",
        "icon":"http://www.dnb.de/SiteGlobals/StyleBundles/Bilder/favicon.png?__blob=normal&v=1"
      }
    },
    {
      "@id":"http://viaf.org/viaf/236493943",
      "collection":{
        "abbr":"VIAF",
        "name":"Virtual International Authority File (VIAF)",
        "publisher":"OCLC",
        "icon":"http://viaf.org/viaf/images/viaf.ico"
      }
    },
    {
      "@id":"http://www.wikidata.org/entity/Q6669738",
      "collection":{
        "abbr":"WIKIDATA",
        "name":"Wikidata",
        "publisher":"Wikimedia Foundation Inc.",
        "icon":"https://www.wikidata.org/static/favicon/wikidata.ico"
      }
    },
    {
      "@id":"https://de.wikisource.org/wiki/London",
      "collection":{
        "abbr":"WIKISOURCE",
        "name":"Wikisource",
        "publisher":"Wikimedia Foundation Inc.",
        "icon":"https://wikisource.org/static/favicon/wikisource.ico"
      }
    },
    {
      "@id":"https://en.wikipedia.org/wiki/London%2C_Wisconsin",
      "collection":{
        "abbr":"enwiki",
        "name":"Wikipedia (English)",
        "publisher":"Wikimedia Foundation Inc.",
        "icon":"https://en.wikipedia.org/static/favicon/wikipedia.ico"
      }
    }
  ]
}

First step: Use EntityFacts to show links (using the icons linke din the JSON) to other resources in the HTML interface.

Possible further step: Enrich JSON-LD with links from EntityFacts. There might be a dump in the future we could build a map from, see https://twitter.com/junicatalo/status/971793109796433926.

The GND relase 2018.02 on 2018-05-15 will bring some additional sub-classes with it. From the announcement:

3. Änderungen in der GND-Ontologie

Die Klasse „gndo:CorporateBody“ erhält vier neue Unterklassen:
„gndo:Company“, „gndo:MusicalCorporateBody“, „gndo:ReligiousCorporateBody“
und „gndo:ReligiousAdministrativeUnit

4. Änderungen in der GND-Konversion

Vier weitere Unterarten von Körperschaften („gndo:CorporateBody“)
werden explizit mit rdf:type als solche ausgezeichnet. Es handelt sich um die
Klassen „gndo:Company“, „gndo:MusicalCorporateBody“,
„gndo:ReligiousCorporateBody“ und „gndo:ReligiousAdministrativeUnit“. Sie sind
jeweils Unterklassen (rdfs:subClassOf) von „gndo:CorporateBody“, vgl. 3. Abschnitt
zur GND-Ontologie. Wie in dem Fall üblich, wird auf eine weitere explizite
Zuordnung zur Oberklasse „gndo:CorporateBody“ verzichtet.

Beispiele in der Testdatei:
http://d-nb.info/gnd/6518137-2, http://d-nb.info/gnd/111260619X,
http://d-nb.info/gnd/2001043-6

Copied from lobid/lodmill#468, originally opened by @nichtich. We should consider this for the new implementation of GND lookup. (I think, @jschnasse also mentioned this.)

For simple lookup it would be nice to add format=suggest in OpenSearch Suggestions format. Format short returns a plain array of strings, e.g. http://api.lobid.org/person?name=Marx&format=short

[
    "Marx, Antônio Augusto (1919-)",
    "Marx, J. A.",
    "Marxsen, Peter Christian (1806-1869)",
    ...
]

OpenSearch Suggestions would be:

[
   "Marx",
   [
       "Marx, Antônio Augusto",
       "Marx, J. A.",
       "Marxsen, Peter Christian",
       ...
   ],
   [
       "Architekt und Künstler (1919-)"
       "Organist und Musiker in Yselstein",
       "Subrektor (1806-1869)",
       ...
   ],
   [
       "http://d-nb.info/gnd/1030092001",
       "http://d-nb.info/gnd/1012540626",
       "http://d-nb.info/gnd/1016221088",
       ...
   ],    
]

We have to automate our data transformation setup for production mode:

• Baseline transformation and indexing, log errors, monitor log
• Update transformation, indexing, logging , monitoring. See also commit comment for 00ca2a6

Both could be triggered via curl POSTs from a cron job (like in lobid-organisations). Calling the transformation from within the web app would result in logging to the application.log (currently calling classes with main methods manually for transformations).

• Set up routes and controllers for triggering baseline and update transformations
• Set up dates to pass to the updates transformation, see also commit comment for 00ca2a6
• Set up cron jobs for triggering the baseline and updates transformation

Server side setup should probably wait until https://github.com/hbz/lobid-webserver/issues/5 is done.

Search yields weird results, e.g.:

• http://test.lobid.org/authorities/search?q=hbz
  (yields all entries, even though @context is not_analyzed)
• http://test.lobid.org/authorities/search?q=london+AND+type:PlaceOrGeographicName
  (perfect match in preferredName for 4074335-4 is between hit 100 and 200)
• http://test.lobid.org/authorities/search?q=preferredName:%22Heine%2C+Heinrich%22
  (no hit, but http://test.lobid.org/authorities/118548018.json exists)

We discussed which filter options we could add. I identified for additional filters that could be useful, two of them only covering persons:

• GND-Sachgruppen: ~11% of all entities have a Sachgruppe associated with them, see http://stage.lobid.org/gnd/search?q=_exists_%3AgndSubjectCategory
• Geographic area code: ~37% of all resources have a geographic area code, see http://stage.lobid.org/gnd/search?q=_exists_%3AgeographicAreaCode

For differentiated persons which account for ~31% of the entries, there are two more:

• dateOfBirth: (~52% of differentiated persons, see http://lobid.org/gnd/search?q=_exists_%3AdateOfBirth&filter=%2B%28type%3ADifferentiatedPerson%29)
• professionOrOccupation (~52% of differentiated persons, see http://lobid.org/gnd/search?q=_exists_%3AprofessionOrOccupation&filter=%2B%28type%3ADifferentiatedPerson%29)

• Think about the labels for the different properties (@acka47)
• Add map view to PlaceOfGeographicname if easy
• General design and layout

This probably has #24 (plus the addition of other labels) as prerequisite.

Currently, the search result list shows name, some variant names and the GND ID with a link to the entry at the DNB. With this ticket we should discuss and implement a more useful result list.

Here are some ideas:

• Neither show the GND ID or a link to the DNB service. It suffices to have this in the detail view
• For Person, show occupation (professionOrOccupation) and birth/death year.
• For ConferenceOrEvents, show place (placeOfConferenceOrEvent) and date (dateOfConferenceOrEvent. (May not be necessary as this is also appended in parentheses to the preferred name.)
• for CorporateBody show placeOfBusiness (more than half of the 1.4 Million corporate bodies have that info).
• For Workwe definitely need firstAuthor/firstComposer,
• For PlaceOrGeographicName show geographicAreaCode
• For SubjectHeading show gndSubjectCategory

For example, http://lobid.org/gnd/2047974-8 makes problems. We might show an image – if available – instead of a second column (see #23).

As resources only have one preferred name, an array isn't needed or might be confusing. Also, we don't have an array for label in lobid-resources so this would be consistant with our other services.

e.g. for 4074335-4

Like Erscheinungsjahr in lobid-resources: http://lobid.org/resources/search

1. Searching for Mark Twain. The resource https://lobid.org/gnd/118624822 should appear as first entry.

• because perfect match with preferredNameEntityForThePerson
• because 118624822 is of type DifferentiatedPerson (DifferentiatedPerson should be preferred over not differentiated datatypes)

2. Searching for 118624822. The resource https://lobid.org/gnd/118624822 should appear as first (and only ?!) entry.

• because perfect match to gndIdentifier

Suggested by @jschnasse, e.g. for http://test.lobid.org/authorities/118540238

E.g. God & spirit, example http://test.lobid.org/gnd/1024589951

e.g. to search for other übernatürliche Wesen from http://test.lobid.org/authorities/4021469-2.html

or who else is acquainted with Charlotte von Stein in http://test.lobid.org/authorities/118540238.html

Copied from lobid/lodmill#75.

To improve disambiguation during auto-suggest selection we should add the profession to auto-suggest labels on the /person endpoint. The information is available through the GND links, but we have to resolve the labels

From #1 (comment):

Furthermore, we should have a type from the second level of GND ontology attached to each resource. We will need this for facetting. GND ontology has three levels in its type hierarchy (except for Person, where we have a fourth one added). see the overview over the GND class hierarchy at https://wiki1.hbz-nrw.de/x/CIeW. In the concrete example, PlaceOrGeographicName should be in the data.

e.g. /authorities/5502844-5

For example http://test.lobid.org/authorities/118506560.

Currently looks like:

{
"professionOrOccupation": [
  "http://d-nb.info/gnd/4131406-2",
  "http://d-nb.info/gnd/4012434-4"
  ]
}

With added labels:

{
   "professionOrOccupation":[
      {
         "id":"http://d-nb.info/gnd/4131406-2",
         "preferredName":"Pianist"
      },
      {
         "id":"http://d-nb.info/gnd/4012434-4",
         "preferredName":"Dirigent"
      }
   ]
}

However, there are several other cases (e.g. placeOfDeath, relatedWork, familialRelationship) where we only have internal GND links without labels in the data. Thus, a general approach would probably make sense to automatically add a label for all URIs from the http://d-nb.info/gnd/ namespace. (If we implement a general approach, it should be possible to exclude some properties from this label enrichment, e.g. we might get problems with trying to fetch the label for deprecatedUri and also labels for sameAs links within GND aren't necessary I think.) What do you think, @fsteeg?

If an authority resource is covered in lobid-resources either in the contribution array or in the subject array, we should show links underneath its entry titled:

• "Zeige Titel von $Agent"
• "Zeige Titel über $Entity"

Clicking on the link will open another browser tab/window with the respective result list.

With the new release on 2018-01-16, there will be somenew properties used in GND data, see the news Änderungen im Format RDF ab 16. Januar 2018 (Export-Release 2018.01), pages 1-3. We will have to update the JSON-LD context to accomodate those changes.

Four abbreviatedName properties:

• gndo:abbreviatedNameForTheConferenceOrEvent
• gndo:variantNameForTheConferenceOrEvent
• gndo:abbreviatedNameForTheWork
• gndo:abbreviatedNameForThePlaceOrGeographicName

Twelve properties from AgRelOn:

• agrelon:hasParent
• agrelon:hasChild
• agrelon:hasSpouse
• agrelon:hasSibling
• agrelon:hasGrandParent
• agrelon:hasGrandChild
• agrelon:hasNieceNephew
• agrelon:hasAuntUncle
• agrelon:hasFriend
• agrelon:hasColleague
• agrelon:hasTeacher
• agrelon:hasStudent

See e.g. http://test.lobid.org/gnd/search?q=*+AND+type:%22CorporateBody%22 where all GND resources are listed with those on top that contain "type" and something similar to "CorporateBody".

For getting labels for URIs like http://d-nb.info/standards/vocab/gnd/geographic-area-code#XA-DE

We should add the date of our latest pull from the GND. So that users don't have to pull all GND files.

Even if the DNB adds the modification date from PICA it wouldn't be optimal as it's changed even if the postbox is used and nothing changes on the norm data itself.

For example:

1. http://test.lobid.org/gnd/search?q=* -> The first 10 hits are all persons starting with "G"
2. Filter by Person -> Not only are the other entities filtered out but the ranking is changed. Now persons with "Person" in their name are shown on top of the list.

Probably the best way to handle this would be to use elasticsearch filters instead of queries for facetting, see https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html (as we do in OER World Map).

BTW, we do it like this in all our services...

We decided to rename the service to lobid-gnd.

• Rename git repo
• Rename Play project
• Change URIs in transformation
• Change HTTP routes
• Change in UI
• Update proxy settings

Currently only linking from result list

See http://www.dnb.de/DE/Service/DigitaleDienste/OAI/oai_node.html

See also implementation in lodmill and lobid-organisations.

From #1 (comment):

Re. the framing output from http://tinyurl.com/ychm4t92, I just noticed that blank nodes get an id:

     "hasGeometry": {
       "@id": "_:b0",
       "@type": "http://www.opengis.net/ont/sf#Point",
       "asWKT": "Point ( -000.125740 +051.508530 )"
     }

We should get rid of them. This has already been addressed in the JSON-LD Framing spec 1.1 ("pruneBlankNodeIdentifiers") but is currently only implemented in the Ruby library, see json-ld/json-ld.org#293.

Test indexing the format from #1 in Elasticsearch.

When there are lots of variant names it doesn't look very good, e.g. https://test.lobid.org/gnd/1083009273

If we show the field at all we should hide it by default like so:

For the result and facet counts, e.g. instead of "4577743" "4.577.743". Keep in mind that we will implement this differently for the – to be added – English version of the service.