Linked Art: An Art Museum Profile for CIDOC-CRM
•Download as PPTX, PDF•
1 like•697 views
Presentation on linked.art at the November 2018 CIDOC-CRM SIG meeting in Berlin, with a focus on modeling decisions and patterns.
Recommended
Recommended
More Related Content
What's hot
What's hot (9)
Similar to Linked Art: An Art Museum Profile for CIDOC-CRM
Similar to Linked Art: An Art Museum Profile for CIDOC-CRM (20)
More from Robert Sanderson
More from Robert Sanderson (15)
Recently uploaded
Recently uploaded (20)
Linked Art: An Art Museum Profile for CIDOC-CRM
- 1. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Linked.Art: An Art Museum Profile for CIDOC-CRM Rob Sanderson Semantic Architect rsanderson@getty.edu @azaroth42 David Newbury Software Architect dnewbury@getty.edu @workergnome https://linked.art/
- 2. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Linked Art Model A Linked Open Usable Data model, collaboratively designed to work across cultural heritage organizations, that is easy to publish and enables a variety of consuming applications. Design Principles: • Focused on Usability, not 100% precision / completeness • Consistently solves actual challenges from real data • Development is iterative, as new use cases are found • Solve 90% of use cases, with 10% of the effort
- 3. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu With thanks to Patrick Hochstenbach, @hochstenbach LOD: Easy to Use … by ... Humans?
- 4. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu LOUD: Easy to Use … by Developers!
- 5. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu The API is the Developers' User Interface When it comes to APIs, developers are your users. The same principles of user- centred-design apply to the development and publication of APIs (simplicity, obviousness, fit-for-purpose etc) http://apiguide.readthedocs.io/en/latest/principles/empathy.html “ ”
- 6. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu
- 7. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Usable vs Complete: Target Zone
- 8. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Successful APIs… Are developed … • Iteratively • We will not get it right first time • Responsively • We will adapt it in response to feedback • Responsibly • We will consider changes/features carefully • Collaboratively • We will engage with the community and stakeholders
- 9. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Linked Art Collaboration Starting work to formalize the profile, funded by Kress • Getty • Rijksmuseum • Louvre • Metropolitan Museum of Art • Smithsonian • MoMA • V&A • NGA • Philadelphia Art Museum • Indianapolis Art Museum • The Frick Collection • Harvard University • Princeton University • Yale Centre for British Art • Oxford University • Academica Sinica • ETH Zurich • FORTH • Zeri Foundation (U. Bologna) • Canadian Heritage Info. Network • American Numismatics Society • Europeana
- 10. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Design Principles • Design for JSON-LD • JSON is the preferred format of developers • JSON-LD lets us map E numbers to dev-friendly terms • As Simple as Possible, but no Simpler • Reduced number of classes, properties • … based on use cases and real world data • Thorough Documentation, with Real Examples • Devs copy examples, they don’t read scope notes • Working examples encourage implementation
- 11. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu JSON-LD 1.1 • Map ontology terms to familiar strings • E22_Man-Made_Object --> ManMadeObject • P1_is_identified_by --> identified_by • All partitioning terms --> part / part_of • Fix collisions e.g. P45 --> made_of • Hide namespaces (considered difficult) • Consistency • If ever multiple values, always an array • Consistent tree structure easier to work with • Automatable with SPARQL and JSON-LD frames
- 12. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Core Features: P2_has_type • Aggressive use of vocabulary over ontology • Normal usage, e.g. Painting • No subclasses of Attribute Assignment • Reduced subclasses of Appellation • Reduced subclasses of Information Object • Extensive classification of Linguistic Object • Map to “classified_as” • Help to distinguish isA class (type) from classification
- 13. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Core Features • No short cuts: A longer route is simpler than multiple • Reduces condition checking code • Can add boiler plate resources copied from examples • No multiple instantiation • If needed, create a new merge class • E.g. Linguistic Object + Appellation --> la:Name • Now: E33_E41_Linguistic_Appellation --> “Name” • Partitioning • Valuable paradigm in core ontology • Missing distinction between membership & parts?
- 14. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu Core Features from External Ontologies • id, type, label, value • No blank nodes! • Every resource has exactly one class • rdfs:label as internal name, recommended • rdf:value (will replace with Pxx_has_string_content) • skos:exactMatch preferred over owl:sameAs
- 17. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu
- 19. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu
- 23. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu
- 24. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu
- 26. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu
- 27. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu New Features: Payment • Payment • Transfer of Monetary Amount between parties • Modeled after Acquisition, Transfer of Custody • Needed for Provenance data • Especially modeling for Art Dealers’ archives • Seems valuable, easy addition?
- 31. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu New Features: Phase • Phase • Time in which some assertion is valid • Modeled after Period + Attribute Assignment • Sub Class Of E2 Temporal Entity • Needed for due to Open World Assumption • Useful for temporal assertions • Accession number valid during Getty phase • Useful for partitioning • Inventory happened during ownership phase • Potential addition / starting point?
- 35. @azaroth42 rsanderson @getty.edu IIIF:InteroperabilituyLinkedArt @azaroth42 rsanderson @getty.edu New Features: Property Interest • Property Interest • A claimed instance of a Right over property, • … with time and place • Modeled after Period + Attribute Assignment • Sub Class Of E71 Man Made Thing • Useful for unequal partitioning of ownership • E.g. two dealers who jointly own a painting • More robust model for sale of stolen items • Probably too specific for base CRM ontology