culturegraph.org is a Linked Open Data service which deals with minting common identifiers (Uniform Resource Identifiers) for cultural works (books and other text, paintings, sculptures, piece of music etc.) to ensure these resources’ reliable and persistent referenceability.
This service (still in its infancy) addresses the fact that one and the same resource has multiple identifiers for metadata – library control numbers as well as publisher’s or bookseller’s IDs like Amazon Standard Identification Number (ASIN) and URI’s stemming from Linked Data efforts. Tying these identifiers together and linking among them is great, but so would be pulling together all the bibliographic descriptive data. Creating *yet another* URI for a certain resource description contributes to the URI synonymy issue (“many URIs for one thing”), but I suppose it serves as an umbrella under which the data can be aggregated.
In any case, it’s good not to neglect already existing non-URI identifiers in information integration, although it seems everything must have a URI these days ;).
Patrick Durusau suggests that properties help identify a subject representative in topic maps. For example, he says that
… All naming conventions are subject to ambiguity and “expanded” naming conventions, such as a list of properties in a topic map, may make the ambiguity a bit more manageable.
That depends on a presumption that if more information is added and a user advised of it, the risk of ambiguity will be reduced. …
In another post, he writes:
… Topic maps provide the ability to offer more complete descriptions of subjects in hopes of being understood by others.
With the ability to add descriptions of subjects from others, offering users a variety of descriptions of the same subject. …
I have some doubts whether this description approach, as opposed to the naming approach (subject indicator and subject locator) now in place in topic maps, will work. IMO, adding more descriptions (by different people with different models of the world, opinions, values, perceptions …) increases the risk of introducing divergent viewpoints and thus runs counter to the original intent (to determine identity and reduce ambiguity). Adding more information is likely to make description and reference more ambiguous, as Pat Hayes and Harry Halpin have argued in their paper “In defense of ambiguity”. Common sense might tell you that the more you define something, pin it down, the more precise it becomes. But precision is not necessarily achieved by more descriptions – subject identification rather gets prone to ambiguity.
Some more questions about identity and disambiguation:
- How do you decide that a description has added a dimension to a concept that makes that concept so different that it becomes “another” concept? Who draws the line (someone else might disagree)? Can we formulate criteria for this process, or is it arbitrary?
- How can we handle time- and context-sensitive descriptions – properties that change over time or according to context? Does a property that changes still define identity, and does identity change too, then? Maybe there are “minor” and “major” properties – if a “major” property changes, does that entail a change of identity, whereas with the change of a “minor”, less typical property identity stays the same? How can either of these “property classes” be determined?
I wonder whether we fall back into the Aristotelian system by stressing description, attributes and properties. Or perhaps description and naming strategies in subject identification can coexist and complement each other.
Mike Bergman, who delivered one of the keynotes at this year’s Dublin Core conference, offers an interesting view of the current state of linked data in an interview for http://semanticweb.com/ (semantic interoperability being one of his main concerns). He raises one point that has been in the back of my mind for quite a while – what is the actual usage of linked data? More specifically, what is being done with the bibliographic datasets released by a number of libraries (CERN leading the way) this year? I’m not aware of mashups or other applications that have been developed using open library data (if they exist, I’d be curious to hear about them). What does that tell us about LOD in the library domain? Granted, it might take some time to gain traction and to convert the data into a friendlier format, yet I can’t help but wonder about the substantial and practical benefit so far.
In order to ensure semantic interoperability, in an ideal world there would be a shared understanding of what concepts and data elements mean. Mapping between terms in different ontologies or between data elements in different formats is alright, but there are deeper issues of how people struggle to represent meaning in computer systems made for others whose model of the world might not be (exactly) the same.
A striking example for the difficulty of semantic interoperability is a Linked Data challenge which sought to answer the question: “Which town or city in the UK has the highest proportion of students?“. One answer puts Cambridge first (you’ll notice the quite obvious mistakes in the data), while another sees Milton Keynes on top. Without digging too deep into the details, one can see that it’s important to make sure the definition of “town”, “city” or “student” is the same in all data sources (Wikipedia, government data…), and to formulate a precise enough query.
The nuances of meaning make a huge difference here. A casual user is unlikely to get the semantics exactly right to match these nuances. Can there be a way to design systems that copes with these intricacies, that can dynamically incorporate context-sensitive and domain-specific semantics, semantic changes over time, locally negotiated semantics as opposed to universal approaches?
While syntactic interoperability is a prerequisite for effective data interchange, a whole host of other factors such as the source of the data, the target group and use cases for which it was produced have to be taken into account when re-using pieces of data. Context influences the semantics of data elements and of their content (a certain concept can have different meanings in different knowledge communities). I’d call this level of interoperability “pragmatic”, drawing on a definition of pragmatics as a subfield of linguistics: it “studies the ways in which context contributes to meaning.”
How are data and data elements actually used in context, and used differently in different contexts? Identifiers and identity conditions may vary depending on context. What about incorrect or inconsistent use of data elements? And what is/are the underlying model(s) that enable applications to share data and interpret them correctly in the given domain? If, for example, we don’t agree on the concept “book” and its properties, how can we effectively share and make sense of data about it? Is data still as valuable when torn out of its original context (Linked Data)?
I suggest that data pragmatics could look at the way people use formats, vocabularies etc. in practice as opposed to a theoretical, top-down, prescriptive view. With the number of people creating and publishing data on the web growing at an unprecedented rate, in this “open world”, we are bound to end up with data of varying quality that may or may not be interoperable on all levels.
Lately some issues and questions have been nagging at me which I’ll explore in future posts.
With linked and open data proliferating in all kinds of domains, interoperability becomes critical. What is syntactic interoperability? In short: If two systems use the same data formats and protocols, they can exchange data without additional effort. Using standards like MARC (encoded in XML) or Z39.50 (to speak for the library world) certainly helps distributed systems to interoperate. But even then the data very often doesn’t work “as is”. Consider, for example, the different “dialects” of MARC. Even though library data is based on the same structural standard, MARC, and on the same rules, AACR2, there are rule interpretations or subtle differences in the use of certain fields from library to library or network to network. More generally, people bring their views, decisions and own internal models of the world to the creation and later use of data (and even to reading a documentation of formats or standards).
Interoperability doesn’t stop at the syntactic level. Adopting syntactic standards is only the basis of the bigger picture. If all data providers used RDF and URIs, would that make all data easily understandable (for machines and humans) and interoperable? Hardly. As William Kent showed in his paper “The many forms of a single fact” (1988), “severe problems of heterogeneity can exist between databases containing the same information in the same type of data structure under the same database processor.” For the moment, I won’t talk about more abstract levels of interoperability – I’ll save that for the next couple of posts…