New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entries of archives without type and with wrong classification #116

Closed
acka47 opened this Issue Mar 8, 2016 · 12 comments

Comments

Projects
None yet
3 participants
@acka47
Contributor

acka47 commented Mar 8, 2016

Got to take a deeper look at this at some point: http://beta.lobid.org/organisations/DE-H368#!

@acka47 acka47 self-assigned this Mar 8, 2016

@acka47

This comment has been minimized.

Contributor

acka47 commented Mar 8, 2016

Another one: http://beta.lobid.org/organisations/DE-2212#!

Both have "classification" : { "id" : "http://purl.org/lobid/libtype#n59" } which is not part of libtype vocab.

@acka47

This comment has been minimized.

@acka47 acka47 changed the title from Entry without type to Entries of archives without type Mar 8, 2016

@acka47

This comment has been minimized.

Contributor

acka47 commented Mar 8, 2016

Seems to be a problem with archives, there's lots of them in http://beta.lobid.org/organisations/search?size=400&q=name:archiv.

According to libtype vocab archives should have classification http://purl.org/lobid/libtype#n85. http://beta.lobid.org/organisations/search?q=classification.id:n85 gives zero results, though...

@acka47 acka47 changed the title from Entries of archives without type to Entries of archives without type and with wrong classification Mar 8, 2016

@acka47 acka47 added the working label Mar 11, 2016

@acka47

This comment has been minimized.

Contributor

acka47 commented Mar 11, 2016

The values are correctly taken from the ISIL registry. Obviously, they have removed the notation "85" for archive (which still is in the libtype vocab) and added different types of archives to the 5* notations. See the documentation: http://sigel.staatsbibliothek-berlin.de/vergabe/adressenformat/805/#c72416

Perhaps @cKlee can say something about this. How could we have realized this change earlier to be able to adapt our data accordingly?

We will have to:

1.Adjust http://purl.org/lobid/libtype.
2. Make sure that we notice classification changes changes up-front in the future.

@acka47

This comment has been minimized.

Contributor

acka47 commented Mar 14, 2016

@fsteeg I am curious how the libtype vocab is incorporated in lobid-organisations data. Will the changes to the vocab from hbz/lobid-vocabs#44 be reflected in the data automatically?

@fsteeg

This comment has been minimized.

Contributor

fsteeg commented Mar 15, 2016

No, I'm afraid not.

As far as I know the vocabulary is only used in the morph: https://github.com/hbz/lobid-organisations/blob/master/src/main/resources/morph-enriched.xml

There, libtype is used in three ways:

  1. A mapping of libtype numbers to URIs (to choose a type for the organisations), stored at http://lobid.org/download/lookup-tables/data/libtype-map.csv
  2. A mapping of libtype numbers to labels (to map Sigel IDs to labels): https://github.com/hbz/lobid-organisations/blob/master/src/main/resources/morph-enriched.xml#L425
  3. A mapping of labels to libtype URIs (to map DBS data to URIs): https://github.com/hbz/lobid-organisations/blob/master/src/main/resources/morph-enriched.xml#L477

If I understand this correctly, the libtype.ttl file currently only provides a place the URIs point to.

Is libtype.ttl used for something else outside of lobid-organisations?

@acka47

This comment has been minimized.

Contributor

acka47 commented Mar 15, 2016

I understand. Then I will have to adjust 1. and 2. after the vocab is updated. As a change to the vocabulary shouldn't happen too often, I think we won't have to change this setup. It is only important to know about those changes early enough.

@cKlee

This comment has been minimized.

cKlee commented Mar 15, 2016

Perhaps @cKlee can say something about this. How could we have realized this change earlier to be able to adapt our data accordingly?

I wasn't aware of the changes either. Will ask my colleague when he's back from Bibliothekskongress.

@acka47

This comment has been minimized.

Contributor

acka47 commented Mar 16, 2016

@cKlee Funny. Please think about a way to communicate those changes in the future. You are welcome to maintain the SKOS vocabulary together with us.

@acka47 acka47 added ready and removed working labels Mar 17, 2016

@acka47 acka47 added working and removed ready labels Mar 31, 2016

acka47 added a commit that referenced this issue Mar 31, 2016

@acka47 acka47 added in progress and removed in progress labels Mar 31, 2016

@acka47 acka47 added review and removed working labels Mar 31, 2016

@acka47 acka47 assigned fsteeg and unassigned acka47 Mar 31, 2016

@fsteeg

This comment has been minimized.

Contributor

fsteeg commented Apr 6, 2016

@fsteeg fsteeg assigned acka47 and unassigned fsteeg Apr 6, 2016

@fsteeg fsteeg removed the in progress label Apr 6, 2016

@fsteeg fsteeg closed this in #124 Apr 6, 2016

@fsteeg fsteeg removed the review label Apr 6, 2016

@acka47 acka47 added the review label Apr 6, 2016

@fsteeg fsteeg reopened this Apr 6, 2016

@acka47

This comment has been minimized.

Contributor

acka47 commented Apr 6, 2016

+1. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment