| Linked Art | https://linked.art/ |
| [email protected] | |
| https://www.linkedin.com/in/robert-sanderson/ | |
| Previously | @azaroth42 on that other site |
Rob Sanderson
- 425 Followers
- 260 Following
- 78 Posts
Senior Director for Digital Cultural Heritage at Yale University. Chair of Linked Art CIDOC WG. Editor for IIIF. Work Interests: GLAM, Linked Data / LOUD, Standards, Integration. Other: Board games, TTRPGs, PS5, Politics
@mike 100% on both! Especially the pub :) Next time I'm in London, I'll let you know!
And yes, expressed badly in limited characters, I meant representing how a particular community sees the situation, which will differ between communities.
And yes, expressed badly in limited characters, I meant representing how a particular community sees the situation, which will differ between communities.
@acka47 Ahh foaf:focus. And madsrdf:identifiesRWO from LC. Yeah, now you have at least linked the problem and the concept of the problem :D
Schema has a very low commitment ... can be good, can be painful when you're looking to build consistency across datasets.
@mike And there are foundational models out there, eg off the top of my head:
* BFO: https://obofoundry.org/ontology/bfo.html
* gist: https://www.semanticarts.com/gist/
* CRM: https://cidoc-crm.org/Version/version-7.2.4
etc. Or, another way to look at it, we can all agree that Lassie is a biological thing, classified as a dog. Some might want further assert agency, some have a different worldview about animals. But if we could at least agree on the higher classes, there'd be a framework for discussion of the specifics
@mike Perhaps if there was a foundational model (Thing, agent, physical thing, conceptual thing, temporal thing [e.g. event or activity], spatial thing [place] etc ...) that we could have all built from in our own directions, we could more easily map between ontologies that refine the conceptual model in different domains? e.g. is skos:Concept a subclass of core:ConceptualThing or a core:Thing? Then it would clearly not work for People.
@mike I know! It's stupid! :( But that's what, in my experience, doesn't work because of the lack of shared conceptual models. Ontology terms aren't like unix commands / lego bricks, as much as I wish they were. The context of the conceptual model of skos (in this case) doesn't work with what we want to say, because people aren't part of a KOS, they're people.
@mike Yes, by using skos:exactMatch ... which then made everything into Concepts instead of People. So we created a new predicate within the ontology (`equivalent`) to capture that relationship without the implications of owl:sameAs or skos terminology
@mike No, but we map all external sources into the conceptual model we use internally to compare apples and apples. Sometimes that mapping is pure guesswork based on element names tho! :(
Is it better than non sem-web? Yes, in that the graph structures and individual representations of entities are much easier to work with, better documented, and tend to link to equivalent records across datasets. e.g. ulan:Rembrandt == lcnaf:Rembrandt, not ulan:Rembrandt residence lcnaf:Amsterdam
@mike Two caveats -- it doesn't work in cultural heritage, but might in more scientific disciplines where distinct conceptual models are more similar; SemWeb as fully distributed system of linking to others' descriptions, to me, is long dead, but harvesting & processing knowledge into a semantic graph from multiple data sources ... that's definitely achievable today, without huge expense.
@edsu And yes, there's some skos concepts in the context that need to come out. InScheme for example should just be member_of to a Set. The exception is skos:broader because the CRM folks said to use it in place of the deprecated CRM ontology equivalent. Not sure I like that as the implications get messy with subclasses of E55_Type, but... /shrug?
@edsu So... we use the CRM conceptual model, expressed with crm plus extensions including linked art terms. One model, one ontology expressed across multiple rdfs files,created by different people. Then we select which to use in the profile, and how to express it as a syntax in the API.