Unlike descriptive metadata (being stable after created), KOS contents (concepts, labels, relationships) are in a constant change mode. There is therefore an issue of how to reflect the changes in linked data set(s), not just within the concept schemes themselves. --MZ
Modeling and KOS
There has been some questioning of this first section, so it would be good to clarify it and modify it if needed. Here is what Antoine said in an email:
- I have some trouble understanding why there is a section 'Conceptual Models and KOS' which is not in the 'Applying SW to LD' one. Is it that you really want 2 analysis paths, one rather separate from linked data implementation issues ('These models do not determine particular technologies'), and the other one only concerned with implementation? Both headers have similar SKOS items below them. This makes the distinction quite blurred for me. This, and the fact that maybe I prefer to see every problem from an implementation perspective anyway
My reply was:
This is the difference between 'what' and 'how'. You might want to look at the Singapore Framework for a vision of the steps and stages. I am thinking that this work is about clarifying and perfecting the domain model and functional requirements.
However, there is much validity in Antoine's concern about modeling apart from the linked data implementation issues. I would like to hear what others think about this, and how we can keep our work from becoming disjointed as we think about our general goals as well as the specific implementation goals. (For example, there probably needs to be significant iteration between goals and implementation.)
This is from Jeff Young:
There is a strong relationship between domain modeling and OWL that should be considered. Here is a symmetrical example from VIAF: http://viaf.org/viaf.jpg http://viaf.org/ontology/1.1/viafOntology.owl. [Sorry about the XSL Stylesheet and incorrect Content-Type on the OWL. We're working on it.]
Reply from Antoine:
I'm not sure I entirely get Jeff's comment, but I think I can understand it in the context of Karen's answer. So, it would be interesting to gather models and question them from a linked data perspective almost independently of their implementation as (OWL) vocabularies. And there would be value in investigating how models are being implemented as vocabularies and applied and re-used in context of LD applications.
Still in that case I think we should put these two categories next to each other. As both of you suggest they're very close parts of a same process. And doing this may help to clarify whether some of the items of one category fit better the other. Take for instance "Dilemma between skos:concept and foaf:person (rda:person, frbr:person, frad:person) for person authorities" in the "implementation" category. Is the idea here to list recipes for choosing between one and the other (or both?) for practical cases? And even then, doesn't that belong to the model part? I'm also curious to hear about others' reactions...
- from kc - I suspect that modeling and implementation will have a crossover, and perhaps we will have to begin the process to discover where that crossover point is. I like Jeff's suggestion that we use OWL as a measure. My experience is that the models that we do have in the library world (mainly the FR's) are under-modeled from a formal standpoint, and will need some modification to transform them from conceptual model to a formal model. The conceptual model will tell us what library thinkers intend, and it is important that the formal model adhere to that intention as much as possible. Ideally there would be some iteration with the developers of the FR's around implementation.
- from ai - I buy this!
Comment from Antoine after this change:
Why are the "characteristics of a common models that embraces the legacy of MARC/FRBR" and the new "Integrating library concept of authorities into Semantic Web model" in the "Applying SW to LD" section now? It seems that the notion of model is quite strongly present in them. Meta-note: I'm sorry for being so nitpicky, Karen, but I'm still trying to understand the idea of the two separate sections, and while I thought I had got it this last move makes it less obvious. Or maybe I'm still unconsciously trying to seize every opportunity to hint that the sections should be merged ;-)
Comment from Jeff Young:
One argument for keeping modeling separate from implementation is that semantics can be extracted from legacy systems in the form of OWL and individuals in the new ontology can be identified and represented at runtime without significant implementation changes. In MVC terms, it's relatively easy to add new Views to the existing Model and Controller. It helps if the implementation has some flexibility for coining HTTP URIs according to a sensible pattern, but it isn't essential. For example, imagine that this URI identifies a FRBR Manifestation and the underlying resource adds support for content-negotiating application/rdf+xml: http://www.worldcat.org/oclc/673595#frbr:Manifestation. Producing a decent FRBR RDF representation from the underlying data is no harder than producing the HTML representation. Granted, http://www.worldcat.org/manifestation/673595 would be a more straightforward URI for this Linked Data real world object, but ultimately they are both just globally-unique resolvable identifiers for a FRBR Manifestation.
- ai (almost there I think): in the model-level discussion we could put stuff like "it's useful to represent manifestations, and here's a model for it!" and in the implementation-level we could point to various implementation cases of HTTP URIs for manifestations?