Hi,
Within the database community, schema first refers to having to fix a data structure (like the attributes in a relational table) before adding data, whereas schema last refers to being able to add schema after data have been added. So, at least to me w.r.t. this more traditional use of the phrase, saying "schema last" isn't quite the right usage, although I think I understand what you are trying to get at.
In general, I don't usually equate an ontology with the notion of a "schema" per se ... For example, we typically use OBOE together with an annotation language, but in doing so, OBOE is not used as the data storage language. Datasets are stored in their native format (tabular datasets), and the annotations can be thought of as specifying views over the underlying data tablse. One can then query the underlying data through the views specified by the annotation language (e.g., for data discovery), but never have to explicitly store data as OBOE instances.
For example, we could require that all instance data be validated with an ontology, and not have a mechansim for updating the ontology in response to the frustrations of our users.
This statement seems contrary to the use of the OWL framework ...
Shawn
On Sat, Feb 19, 2011 at 6:32 PM, joel sachs jsachs@csee.umbc.edu wrote:
Hi Shawn,
On Thu, 17 Feb 2011, Shawn Bowers wrote:
Hi Joel,
I think the OWL model in general is "schema-last".
A good point, although I would phrase it differently and say that rdf, in general, is highly compatible with schema-last. But it's also compatible with decidedly non schema-last practices. For example, we could require that all instance data be validated with an ontology, and not have a mechansim for updating the ontology in response to the frustrations of our users.
Anyway, I'd be happy to stop using the phrase, and instead talk about specifics of what our ontologies should look like, and where they should come from.
Regards, Joel.
In particular, the only fixed "schema" is the triple model (subject, predicate, object), and one can add and remove triples as needed. I don't think OBOE or EQ (or any other OWL ontology) is any more schema-first versus schema-last than the other -- since they are based on OWL/RDF. Alternatively, a particular dataset (with specific attributes) is a typical example of "schema first", i.e., before I can store data rows, I have to define the attributes (so this would be true in, e.g., Darwin Core). In both OBOE and EQ, one could have a set of triples, and then come along later at any time and add triples that give type information to existing individuals, etc. Both OBOE and EQ do introduce classes that prescribe how to structure new classes and type individuals -- but it would be really hard given this to say one is more "schema last" than the other because of these basic upper-level classes.
Shawn
On Thu, Feb 17, 2011 at 11:28 AM, joel sachs jsachs@csee.umbc.edu wrote:
Hilmar,
I guess I'm now guilty of conflating concepts myself, namely "instance-data generation as an integral component of the ontology development spiral", and "schema last". They're distinct, but related in the sense that the latter can be seen as an extreme case of the former. Separating them:
Instance Data. Do you (or does anyone else on the list) know the status of OBD? From the NCBO FAQ:
What is OBD? OBD is a database for storing data typed using OBO ontologies
Where is it? In development!
Is there a demo? See http://www.fruitfly.org/~cjm/obd
Datasets See the above URL for now
But the demo link is broken, and it's hard to find information on OBD that isn't a few years old. Is it still the plan to integrate OBD into BioPortal? If not, then maybe the "Missing Functionality [of BioPortal]" section of the KOS report should include a subsection about providing access to instance data. Considering GBIF's data holdings, it seems like it would be a shame to not integrate data browsing into any ontology browsing infrastructure that GBIF provides.
Schema Last. I think schema-last is a malleable enough buzzword that we can hijack it slightly, and I've been wondering about what it should mean in the context of TDWG ontologies. Some ontology paradigms are inherently more schema-last-ish than others. For example, EQ strikes me as more schema-last-ish than OBOE or Prometheus. Extending an example from the Fall, EQ gives:
fruit - green bark - brown leaves - yellow leaves - ridged leaves - broad
and OBOE gives
fruit - colour - green bark - colour - brown leaves - colour - yellow leaves - perimeter texture - ridged leaves - basic shape - broad
So in the OBOE case, the characteristics (color, perimeter texture, basic shape) are given a priori, while in the EQ case they would (presumably) be abstracted during subsequent ontology development. In theory, these two approaches may be isomorphic, since, presumably, the OBOE characteristics are also abstracted from examples collected as part of the requirements gathering process. In practice, though, I suspect that EQ leaves more scope for instance-informed schemas. I have no basis for this suspicion other than intiuition, and would welcome any evidence or references that anyone can provide.
Also, schema-last could perhaps be a guiding philosophy as we seek to put in place a mechanism for facilitating ontology update and evolution. For example, it might be worth experimenting with tag-driven ontology evolution, as in [1], where tags are associated to concepts in an ontology. If a tag can't be mapped into the ontology, the ontology engineer takes this as a clue that the ontology needs revision. So the domain expert/knowledge engineer partnership is preserved, but with the domain expert role being replaced by collective wisdom from the community. Passant's focus was information retrieval, where the only reasoning is using subsumption hierarchies to expand the scope of a query, but the principle should apply to other reasoning tasks as well. The example in my mind is using a DL representation of SDD as the basis for polyclave keys. When users enter terms not in the ontology, it would trigger a process that could lead to ontology update.
I don't dispute the importance of involving individual domain experts, especially at the beginning, but also throughout the process. And I agree that catalyzing this process is, indeed, a job for TDWG.
Joel.
On Tue, 15 Feb 2011, Hilmar Lapp wrote:
Hi Joel -
I'm in full agreement re: importance of generating instance data as driving principle in developing an ontology. This is the case indeed in all the OBO Foundry ontologies I'm familiar with, in the form of data curation needs driving ontology development. Which is perhaps my bias as to why I treat this as implicit.
That being said, it has also been found that in specific subject areas progress can be made fastest if you convene a small group of domain experts and simply model the knowledge about those subject areas, rather than doing so piecemeal in response to data curation needs.
BTW I don't think Freebase is a good example here. I don't think the model of intense centralized data and vocabulary curation that it employs is tenable within our domain, and I have a hard time imagining how schema-last would not result in an incoherent data soup otherwise. But then perhaps I just don't understand what you mean by schema-last.
-hilmar
Sent with a tap.
On Feb 15, 2011, at 8:24 PM, joel sachs jsachs@csee.umbc.edu wrote:
Hi Hilmar,
No argument from me, just my prejudice against "solution via ontology", and my enthusiasm for "schema-last" - the idea that the schema reveals itself after you've populated the knowledge base. This was never really possible with relational databases, where a table must be defined before it can be populated. But graph databases (expecially the "anyone can say anything" semantic web) practically invite a degree of schema-last. Examples include Freebase (schema-last by design), and FOAF, whose specification is so widely ignored and mis-used (often to good effect), that the de-facto spec is the one that can be abstracted from FOAF files in the wild.
The semantic web is littered with ontologies lacking instance data; my hope is that generating instance data is a significant part of the ontology building process for each of the ontologies proposed by the report. By "generating instance data" I mean not simply marking up a few example records, but generating millions of triples to query over as part of the development cycle. This will indicate both the suitability of the ontology to the use cases, and also its ease of use.
I like the order in which the GBIF report lists its infrastructure recommendations. Persistent URIs (the underpinning of everything); followed by competency questions and use cases (very helpful in the prevention of mental masturbation); followed by OWL ontologies (to facilitate reasoning). Perhaps the only placewhere we differ is that you're comfortable with "incorporate instance data into the ontology design process" being implicit, while I never tire of seeing that point hammered home.
Regards - Joel.
On Mon, 14 Feb 2011, Hilmar Lapp wrote:
On Feb 14, 2011, at 12:05 PM, joel sachs wrote:
> I think the recommendations are heavy on building ontologies, and > light on suggesting paths to linked data representations of instance data.
Good observation. I can't speak for all of the authors, but in my experience building Linked Data representations is mostly a technical problem, and thus much easier compared to building soundly engineered, commonly agreed upon ontologies with deep domain knowledge capture. The latter is hard, because it requires overcoming a lot of social challenges.
As for the GBIF report, personally I think linked biodiversity data representations will come at about the same pace whether or not GBIF pushes on that front (though GBIF can help make those representations better by provisioning stable resolvable identifier services, URIs etc). There is a unique opportunity though for "neutral" organizations such as GBIF (or, in fact, TDWG), to significantly accelerate the development of sound ontologies by catalyzing the community engagement, coherence, and discourse that is necessary for them.
-hilmar
=========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : ===========================================================
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content