[Dini-ag-kim-titeldaten] Re: [dini-ag-kim-lld] dc:creator oder dct:creator

Don Apr 4 17:10:04 CEST 2013

Hallo Philipp,

 > Würde dies auch bedeuten, dass man längerfristig
 > bei Text-Strings dcterms in Kominbation etwa mit
 > Blank nodes verwenden soll?

m. E. eine wichtige Frage. Ich werde die jetzt einfach mal an Tom Baker 
weiterschicken. Mal sehen, ob er was dazu sagen kann.

Melde mich, sobald ich eine Rückmeldung habe.

Gruß aus Göttingen

     Stefanie

Am 02.04.2013 17:06, schrieb Philipp Zumstein:
> Hallo zusammen,
>
> hauptsächlich möchte ich einige Fragen und evt. Anregungen in die 
> Diskussion werfen:
>
> Bei dc-element sind sowohl Strings, Ressourcen (z.B. über URIs) wie 
> auch RDF-Konstrukte für Listen zulässig. Dies kann zu sehr 
> unterschiedlich aussehenden Inhalten bei dc:creator führen (vgl. [2], 
> wobei foaf:maker für uns wohl uninteressant ist).
>
> Bei [1] kann man lesen: "Over time, however, implementers are 
> encouraged to use the semantically more precise dcterms: properties, 
> as they more fully follow emerging notions of best practice for 
> machine-processable metadata." Würde dies auch bedeuten, dass man 
> längerfristig bei Text-Strings dcterms in Kominbation etwa mit Blank 
> nodes verwenden soll?
>
> Wie kann man in SPARQL nach Dokumenten mit mehr als einem creator suchen?
>
>
> Anwendungen sehe ich neben den bereits erwähnten Kataloganwendungen 
> ebenfalls in Mashups basierend auf Linked Data aus verschiedenen 
> Quellen. Dabei wird man aber sowieso unterschiedliche Modellierungen 
> (dc, dct, String, Literal, Blank Node, etc.) antreffen und 
> entsprechende Fallunterscheidungen einbauen müssen.
>
>
> Mit besten Grüßen,
> Philipp
>
>
> [1] http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces
> [2] http://wiki.foaf-project.org/w/UsingDublinCoreCreator
>
>
>
>
> Am 28.03.2013 12:54, schrieb Neubert Joachim:
>> Hallo Pascal,
>>
>> ok, als Suchmaschinenpraktiker hast du da gleich einen Fall, wo die 
>> nicht individualisierten PNDs nützlich sein könnten. Trotzdem ist das 
>> eine Abwägung: Wenn in dc:creator _entweder_ eine URI _oder_ ein 
>> Literal stehen kann, muss jede Anwendung diese Fallunterscheidung 
>> treffen (und ggf. ein Lookup vornehmen), bevor der Name angezeigt 
>> werden kann. M.E. ist es leichter intellektuell nachvollziehbar und 
>> insgesamt kostengünstiger, wenn Such-Anwendungen für alternative 
>> Ansetzungsformen ein Lookup auf den Namensstring machen müssen (zumal 
>> dann die Varianten aus den individualisierten PNDs wahrscheinlich 
>> auch interessieren).
>>
>> Schöne Grüße, Joachim
>>
>>> -----Original Message-----
>>> From: Pascal Christoph [mailto:christoph at hbz-nrw.de]
>>> Sent: Wednesday, March 27, 2013 5:29 PM
>>> To: Informationsaustausch der DINI AG KIM Linked Library Data Gruppe
>>> Cc: Neubert Joachim; dini-ag-kim-titeldaten at lists.d-nb.de
>>> Subject: Re: [dini-ag-kim-lld] dc:creator oder dct:creator
>>>
>>> Hallo Joachim,
>>>
>>> Am 27.03.2013 16:14 schrieb Neubert Joachim :
>>>
>>>> Die nicht individualisierten PNDs bieten m.E. jedenfalls in diesem 
>>>> Kontext
>>> keinen zusätzlichen Nährwert und sollten gleich durch den Namensstring
>>> ersetzt werden.
>>>
>>> Ganz so weit würd ich nicht gehen, immerhin bietet die URI für den
>>> Namensstring verschiedene Schreibweisen an[1]. Und diese können
>>> nützlich sein, z. B. im Suchmaschinenindex.
>>>
>>> viele Grüße, pascal
>>>
>>> [1]Beispiel: http://d-nb.info/gnd/177351942
>>>
>>>> Schöne Grüße, Joachim
>>>>
>>>>> -----Original Message-----
>>>>> From: dini-ag-kim-lld-bounces at lists.d-nb.de [mailto:dini-ag-kim-lld-
>>>>> bounces at lists.d-nb.de] On Behalf Of Hauser, Julia
>>>>> Sent: Wednesday, March 27, 2013 3:00 PM
>>>>> To: Informationsaustausch der DINI AG KIM Linked Library Data Gruppe;
>>>>> dini- ag-kim-titeldaten at lists.d-nb.de
>>>>> Subject: AW: [dini-ag-kim-lld] dc:creator oder dct:creator
>>>>>
>>>>> Lieber Pascal, liebe KollegInnen,
>>>>>
>>>>> ich sende deine Mail gleich an die Titeldaten-Mailingliste weiter,
>>>>> denn hier müssen wir die Frage unbedingt noch einmal thematisieren.
>>>>>
>>>>> Viele Grüße,
>>>>> Julia
>>>>>
>>>>>
>>>>> ***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***
>>>>> -- 
>>>>> Julia Hauser
>>>>> Deutsche Nationalbibliothek
>>>>> Informationstechnik
>>>>> Adickesallee 1
>>>>> D-60322 Frankfurt am Main
>>>>> Telefon: +49-69-1525-1784
>>>>> Telefax: +49-69-1525-1799
>>>>> mailto:j.hauser at dnb.de
>>>>> http://www.dnb.de
>>>>>
>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: dini-ag-kim-lld-bounces at lists.d-nb.de
>>>>>> [mailto:dini-ag-kim-lld-bounces at lists.d-
>>>>>> nb.de] Im Auftrag von Pascal Christoph
>>>>>> Gesendet: Mittwoch, 27. März 2013 14:37
>>>>>> An: Informationsaustausch der DINI AG KIM Linked Library Data Gruppe
>>>>>> Betreff: [dini-ag-kim-lld] dc:creator oder dct:creator
>>>>>>
>>>>>> Hallo liebe *,
>>>>>>
>>>>>> am 26.3. haben wir auf der DINI AG KIM Workshop 2013 über die
>>>>>> "Empfehlung für die RDF-Repräsentation bibliografischer Daten
>>>>>> (Textressourcen)"[1] diskutiert, ob nicht dct:creator besser wäre
>>>>>> als
>>>>> dc:creator, wenn eine URI vorhanden ist[1].
>>>>>> Einige Teilnehmer haben sich für die dct Variante stark gemacht,
>>>>>> darunter
>>>>> auch ich.
>>>>>> Und dabei haben wir, zumindest ich selbst, etwas wichtiges vergessen
>>>>>> oder wenigstens nicht ausgesprochen, nämlich dass es nicht
>>>>>> ausreicht, lediglich eine (PND-)URI zu haben - es ist zudem wichtig,
>>>>>> dass diese URI auch tatsächlich die _individualisierte_ URI ist,
>>>>>> also eine Person bezeichnet, und nicht etwa nur ein Identifier für
>>>>>> einen Namen. Ist aber ersteres gegeben , und da die Daten der gnd
>>>>>> eine automatisierte Diskriminierung zulassen, spreche ich mich
>>>>>> weiterhin dafür aus, diese
>>>>> Personen-URIs unter dct zu subsumieren, und zwar u.
>>>>>> a. genau aus dem oben genannten Grund:
>>>>>> Z.B. Facetten über dct:creator bedeuten, dass ich alles genau über
>>>>>> diese Person erhalte. Facetten über dc:creator garantieren dies 
>>>>>> nicht.
>>>>>>
>>>>>> (In lobid.org haben wir aus Bequemlichkeitsgründen _vorerst_ alle
>>>>>> PND-Uris mit dc
>>>>>> prädikatisiert.[2])
>>>>>>
>>>>>> Jetzt könnten wir an dieser Stelle natürlich das Fass aufmachen, die
>>>>>> URIs für Namen endlich durch Personen-URIs zu ersetzen. Dies
>>>>>> Desiderat bleibt jedenfalls.[3]
>>>>>>
>>>>>> -o
>>>>>>
>>>>>> [1]https://wiki.dnb.de/pages/viewpage.action?pageId=68061169
>>>>>> [2]Beipiel: http://lobid.org/resource/HT002189125
>>>>>> [3]Etwas Hintergrund von Oliver Flimm (im Blog-Post suchen nach
>>>>>> "Personen-Normdaten"):
>>>>>> http://blog.openbib.org/2012/04/17/mehr-aus-den-daten-in-katalogen-
>>>>> hera
>>>>>> usholen/ _______________________________________________
>>>>>> dini-ag-kim-lld mailing list
>>>>>> dini-ag-kim-lld at lists.d-nb.de
>>>>>> http://lists.d-nb.de/mailman/listinfo/dini-ag-kim-lld
>>>>> _______________________________________________
>>>>> dini-ag-kim-lld mailing list
>>>>> dini-ag-kim-lld at lists.d-nb.de
>>>>> http://lists.d-nb.de/mailman/listinfo/dini-ag-kim-lld
>>>> _______________________________________________
>>>> dini-ag-kim-lld mailing list
>>>> dini-ag-kim-lld at lists.d-nb.de
>>>> http://lists.d-nb.de/mailman/listinfo/dini-ag-kim-lld
>>>>
>>
>> _______________________________________________
>> dini-ag-kim-lld mailing list
>> dini-ag-kim-lld at lists.d-nb.de
>> http://lists.d-nb.de/mailman/listinfo/dini-ag-kim-lld
>>
>
>

-- 
Stefanie Rühle
Metadata and Data Conversion

Georg-August-Universität Göttingen
Göttingen State and University Library
D-37070 Göttingen

Papendiek 14 (Historical Building, room 1.603)
+49 551 39-10905 (Tel.)

sruehle at sub.uni-goettingen.de