[tdwg-content] More schema-last (was Monkey Business)

[joel sachs]

Shawn,

I'm not sure if we're agreeing. Comments below ...

On Sat, 19 Feb 2011, Shawn Bowers wrote:

> 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.

Even in an rdbms, you can add schema after data, for example with "Alter 
Table". RDF is different in that i) the schema can be distributed, and 
ii) the schema definition and data definition languages are the same. So 
it is literally true that "schema is data too". So, to the extent that it 
makes sense to use a term like schema-last, it seems reasonable to apply 
it to practices rather than languages.

The first several years of the sematic web were hampered by the attitude 
that, to be on the semantic web, you first need an ontology. My guess is 
that many in TDWG believe this to be true, due to the emphasis we've 
placed on ontologies over the years. "Ontologies where necessary, but not 
necessarily ontologies" strikes me as a good motto for the semantic web.


> 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.

Could you point me to endpoints where I can query data via the 
OBOE ontology?

>
>> 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 ...

It's contrary to common sense, but compatible with OWL. If I'm exagerating 
about ontologies not being responsive to the frustrations of their users, 
it's because most ontologies don't have users. I'll check Swoogle for 
some statistics to back that up, but does anyone really dispute it?


Joel.


>
> Shawn
>
> On Sat, Feb 19, 2011 at 6:32 PM, joel sachs <jsachs at 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 at 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.
>>>>
>>>> 1. Passant, http://www.icwsm.org/papers/paper15.html
>>>>
>>>>
>>>> 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 at 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 at lists.tdwg.org
>>>> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>>>>
>>
>