search

ARUP-CAS / aiscr-dapro

OAI-PMH Data Provider pro AMČR
https://api.aiscr.cz/
GNU General Public License v3.0
2 stars 0 forks source link

tag identifier #2

Closed motyc closed 5 years ago

motyc commented 5 years ago

Pročítal jsem ještě specifikaci OAI-PMH a vzhledem k tomu, že všechny identifikátory by měly být vyjádřeny jako validní absolutní URI, prosím sjednoťme obsah tohoto tagu na: https://api.aiscr.cz/id/[ident_cely]

Vím, že jsem na schůzce chtěl naopak https://api.aiscr.cz/id/ vypustit, ale bude lepší držet se standardu.

motyc commented 5 years ago

Ještě se na to dívám blíže a druhou možností by bylo použít specifikaci podle http://www.openarchives.org/OAI/2.0/guidelines-oai-identifier.htm

Pak by identifikátor vypadal: oai:api.aiscr.cz:[ident_cely]

Co myslíte, že je lepší? Takto by se rozlišily unikátní ID uvnitř RDF a ID pro OAI... Možná bych se spíš přiklonil k této variantě.

Výhodou je i to, že se to pak dá snadno definovat v rámci Identify.

vbar commented 5 years ago

Mně by přišlo vhodnější kdyby bylo unikátní ID jen jedno - nebo je nějaký specifický důvod proč by RDF mělo mít jiná ID než OAI-PMH?

motyc commented 5 years ago

Tady si asi nerozumíme. Samozřejmě v tagu <identifier> by bylo vždy oai:api.aiscr.cz:[ident_cely] (např. oai:api.aiscr.cz:C-201800019) ve všech schématech.

Myslím tím to, že se tak OAI ID odliší od údaje, který je v rdf:about= u každé jednotlivé třídy v RDF (např. <crm:E7_Activity rdf:about="https://api.aiscr.cz/id/C-201800019">). Je to ostatně ID hlavně pro případné vytváření LOD endpointu a to by asi mělo být odlišné od OAI.

vbar commented 5 years ago

Já bych řekl že ty alternativy chápeme stejně - akorát máme různé preference... Mně není jasné proč by se OAI ID (v tagu <identifier> ) mělo lišit od RDF ID (v atributu rdf:about) - OAI-PMH i RDF přece používají pro své identifikátory URL právě proto aby se ten samý identifikátor dal použít napříč aplikacemi... A kdybysme časem zprovoznili něco na https://api.aiscr.cz/id/[ident_cely] , není nic špatného na tom když OAI-PMH identifikátory začnou fungovat i jako linky...

motyc commented 5 years ago

Ok, pak to tak tedy udělejme a je vyřešeno. Upravím ještě patřičně odpověď na "Identify", aby to bylo kompatibilní. Možná v tom vidím zbytečné složitosti.

vbar commented 5 years ago

Identifier se tedy používá https://api.aiscr.cz/id/[ident_cely] , což ovšem nefunguje pro soubory, které žádný ident_cely nemají - jak ty bysme měli identifikovat? Podle filepath?

motyc commented 5 years ago

Ano, přesně tak.

motyc commented 5 years ago

Ještě není implementované pro soubory...

vbar commented 5 years ago

Upravil jsem pro soubory (v gitu, ještě není nasazeno), ale podobný problém má hledání externích zdrojů v RDF formátu: např. X-BIB-0709996 má patrně v RDF souboru záznam <crm:E33_Linguistic_Object rdf:about="https://api.aiscr.cz/id/X-BIB-0709996-part1"&gt; , takže identifikátor https://api.aiscr.cz/id/X-BIB-0709996 se nenajde... Mají mít externí zdroje různé ID pro formát AMCR vs. RDF?

motyc commented 5 years ago

Myslím, že se jen díváte na špatnou část záznamu. Externí zdroj je popsaný na úrovni <crm:E31_Document rdf:about="https://api.aiscr.cz/id/X-BIB-0709996">. Ten tag <crm:E33_Linguistic_Object rdf:about="https://api.aiscr.cz/id/X-BIB-0709996-part1"> označuje až externí odkaz,, který není persistentní (z pohledu AMČR) a ani se podle něj filtrovat nemá.

vbar commented 5 years ago

Hmm, a jak poznám tu správnou část? Počítal jsem že záznamy jsou prostě ty elementy které jsou v RDF grafu na nejvyšší úrovni (pod <rdf:RDF>, jako <crm:E7_Activity> pro projekty) a jejich ID je v rdf:about toho elementu...

vbar commented 5 years ago

Po zralé úvaze, myslím že tohle by se mělo řešit změnou mappingu - ID záznamu by měl mít RDF subjekt, který není objektem žádného RDF statementu (takže se v serializaci do XML objeví nahoře). V CRM se to dá udělat beze změny sémantiky, protože všechny CRM predikáty lze invertovat. Taky je pravda že tento problém až tak nesouvisí s formátem identifikátoru - k další diskusi můžeme udělat novou issue, případně znovuotevřít #79...