Separate subject chains from another in subject array #187
Comments
And yes, this really is valid JSON-LD and no "lists in lists" error is thrown, see this example in the JSON-LD playground. |
This can be simplified with {
"@context": {
"componentList": {
"@id": "http://www.loc.gov/mads/rdf/v1#componentList",
"@container": "@list"
},
"subject": "http://purl.org/dc/elements/1.1/subject",
"id": "@id"
},
"id": "http://lobid.org/resources/HT013099804#!",
"subject": [
{
"type": "madsrdf:ComplexSubject",
"componentList": [
{
"id": "http://d-nb.info/gnd/4032952-5",
"label": "Krefeld",
"type": [
"PlaceOrGeographicName"
]
},
{
"id": "http://d-nb.info/gnd/4041156-4",
"label": "Naherholungsgebiet",
"type": [
"SubjectHeading"
]
},
{
"id": "http://d-nb.info/gnd/4125082-5",
"label": "Freizeitverhalten",
"type": [
"SubjectHeading"
]
},
{
"id": "http://d-nb.info/gnd/4061619-8",
"label": "Umweltbelastung",
"type": [
"SubjectHeading"
]
}
]
}
]
} As far as I know, the use of In JSKOS draft I use the JSON key
|
Thanks, Jakob. Interestingly, you can also make the subject array a list and it is ok in the JSON Playground. But I guess the order of the subject chains is not important so we can ignore this. {
"@context":{
"componentList":{
"@id":"http://www.loc.gov/mads/rdf/v1#componentList",
"@container":"@list"
},
"subject":{
"@id":"http://purl.org/dc/terms/",
"@container":"@list"
},
"id":"@id"
},
"id":"http://lobid.org/resources/HT013099804#!",
"subject":[
{
"type":"madsrdf:ComplexSubject",
"componentList":[
{
"id":"http://d-nb.info/gnd/4032952-5",
"label":"Krefeld",
"type":[
"PlaceOrGeographicName"
]
},
{
"id":"http://d-nb.info/gnd/4041156-4",
"label":"Naherholungsgebiet",
"type":[
"SubjectHeading"
]
},
{
"id":"http://d-nb.info/gnd/4125082-5",
"label":"Freizeitverhalten",
"type":[
"SubjectHeading"
]
},
{
"id":"http://d-nb.info/gnd/4061619-8",
"label":"Umweltbelastung",
"type":[
"SubjectHeading"
]
}
]
},
{
"type":"madsrdf:ComplexSubject",
"madsrdf:componentList":[
{
"id":"http://d-nb.info/gnd/4032952-5",
"label":"Krefeld",
"type":[
"PlaceOrGeographicName"
]
},
{
"id":"http://d-nb.info/gnd/4041156-4",
"label":"Naherholungsgebiet",
"type":[
"SubjectHeading"
]
},
{
"id":"http://d-nb.info/gnd/4280189-8",
"label":"Sportverhalten",
"type":[
"SubjectHeading"
]
},
{
"id":"http://d-nb.info/gnd/4061619-8",
"label":"Umweltbelastung",
"type":[
"SubjectHeading"
]
}
]
}
]
} |
I seem to recall that the order is actually consciously cataloged. Like 1. topic, 2. topic etc. |
To my knowledge the order of the chains does not carry any semantic importance, it is merely a matter of the order of the topics as they occur in the document. The order of the terms in the chain of course do matter. I guess the ultimate answer can be found in the RSWK (or other relevant cataloguing code). |
<rant> Instead of subject-chains, users down-drill big result-sets using facets (which are build upon solely subjects), restricting the resulting result set further by down-drilling using another facet on that result-set etc. |
This issue is an example of underestimating RSWK. It makes only limited sense to keep track of the terms and use syntactic indexing. This is like catalog card era where librarians wrote subject terms (descriptors) down in order, in the hope the catalog user is able to navigate over the catalog titles. A more powerful use of RSWK subject is linking. You can link between subjects following rules. Example: Imagine RSWK-Schlagwortkette Sierra Leone ; Schule ; Bildungshilfe ; Geschichte This can be modeled in Turtle-RDF like the following sketch
A title
or
or
The |
Currently, we put DDC (from 700) and GND subjects (from 9--s) both into one subject list, see e.g. http://lobid.org/resources/HT006932194. @dr0i now asks whether the On the other hand, there are a lot of entries with only one subject where a complex subject seems to be too much... |
@jprante Thanks for the ideas. As the coverage with subject chains isn't very good for now in the lobid data, we are now focusing on adequately representing subject chains in the RDF for display purposes. To implement solutions for more sophisticated use cases which you describe, we don't have the time and resources. For browsing and searching with subject chains, we have a feature in the NWBib called Themensuche, see http://nwbib.de/topics. It is based on strings for each subject chain which are build concatenating the preferred names with seperator |
@dr0i http://lobid.org/resources/HT006932194 only contains simple DDC entries:
so this is no good example for |
We decided to only use the |
One more question: |
Since all is covered by the |
In API 1.0, we only used the data from |
As discussed today in the stand up, please go ahead and remove |
With 'componentList' the chained subjects are already covered. This 'subjectChain' is superfluous. Complements #187.
In hbz/nwbib#363 (comment) I wrote:
@dr0i said in response:
I wouldn' t have brought this up again but today @larsgsvensson made me aware over at the DINI KIM Titeldatengruppen Wiki that there exists a way to express this with MADS RDF which would actually not look bad in our JSON-LD. For the example document http://lobid.org/resources/HT013099804 this would look like this (only writing down the interesting parts):
The text was updated successfully, but these errors were encountered: