Re: Press.net News Ontology

Hi Paul,

On 9 Sep 2011, at 15:28, Paul Wilton <paul.wilton@ontoba.com> wrote:

> Hi again Bob
> 
> Many complex/rich domain ontologies can be constructed pretty much
> solely from the building blocks of the high level public domain
> ontologies like foaf, event, time, dc etc.

The British library's recently published model is just such an example.  The British library were keen to describe their data using commonly used defacto properties and classes where possible.  This makes it very easy for other people to look at and understand the relationships.  The BL only coined a handful of properties in their own namespace for things that didn't exist with the right meaning or domains/ranges.

> But if this was the way domain experts worked then everyone would end
> up doing things slightly differently in the same domain.

Not if those domain experts are good at sharing ideas with each other.

> By producing
> a namespaced ontology of this nature, we demonstrate and offer up a
> standardised approach to publishing news assets in RDF and their
> relationships to the world.
> We thus say, if you do your news this way, everyone will be publishing
> news plus events, foaf, locations etc in the same manner with the same
> joining relationships.

That can happen without using a strictly namespaced ontology.

> This is where the value of the ontology lies (and for that matter, any
> rich namespaced ontology constructed from those building blocks in
> some other domain).
> The practical problem of contract binding is very real, and it
> surfaces when technical architects have to build robust applications
> around a rich ontology. This where the rest of the value arises. Of
> course you can bind to the terms in the other ontologies just as
> easily, but this can end up being costly for an organisation in the
> long term. Just as a sensible architect decouples his own clients/APIs
> from underlying components so those components can be switched out
> without affecting the interfaces (contracts) that client systems have
> bound too. If those systems were bound directly to the underlying
> components then the cost of change becomes very high. The principle is
> the same. It is all very well looking at this through purists eyes,
> but if the semantic web is going to succeed then practical issues such
> as this need to be addressed in order that robust systems can be
> built.

Robust systems that use data that may or may not be there are being built. They don't require that the ontology validates how the data should look, but that the ontology describes the sort of data they may find.  The application builder needs to be aware, and program for the case when an 'expected' value is not present.  This is the nature of the web of documents, we have http response codes for that.  The same is possible in the web of data.


> 
> With respect to the event transitivity, I did speak with Yves who
> authoured the event ontology and he has a very good reason for not
> introducing transitivity into it as it stands.
> 
> kind regards
> Paul
> 
> 
> On Fri, Sep 9, 2011 at 1:59 PM, Bob Ferris <zazi@smiy.org> wrote:
>> Hi Paul,
>> 
>> thanks a lot for your reply.
>> 
>> On 9/9/2011 11:20 AM, Paul Wilton wrote:
>>> 
>>> Hi Bob
>>> In most of these cases you have pointed out, we have inherited from
>>> the classes/properties
>> 
>> Even inheriting a term should be done carefully, i.e., it should especially
>> come along with a concrete plausible definition which differs from that of
>> the inherited term. Reasoning is still an expensive task today. Try to
>> express as much knowledge in a direct way.
>> 
>>> you mention for very good practical reasons,
>>> either as we want to specialise further the class in question (eg
>>> sub_event on the public domain event ontology was not transitive, so
>>> we have defined our own specialized property that is transitive).
>> 
>> Well, regarding the concrete example you've mentioned, you could propose
>> this change also to the authors of the Event Ontology (especially, since the
>> project source was recently moved to GitHub [1], you could init a Pull
>> Request; that's a way how modern ontology could be done in a shared,
>> collaborative environment).
>> 
>>> The other very practical reason is that we *want* to define a ontology
>>> for news with its own classes and predicates.
>> 
>> Yes, this always looks to me like database schema or MDA modelling.
>> 
>>> We have subclassed
>>> public domain ontologies where we feel the public domain ontology is
>>> widely used, so that when RDF is published we wil also be publishing
>>> the ancestor classes and properties for consumers that understand it.
>> 
>> So you'll materialize all the way down?
>> 
>>> This also addresses the practical architectural problem of contract
>>> binding. Developers of APIs built around this ontology can bind  to
>>> the press.net classes and properties, decoupling themselves from
>>> public domain ontologies which our out of their control.
>> 
>> They can bind the press.net terms as easily as terms of other namespaces
>> (I'm waiting for the muddy counter argument: "don't confuse us with to much
>> namespaces"). Furthermore, the press.net ontologies are looking to me like
>> public domain ontologies (of the news domain) as well more or less.
>> 
>>> As these
>>> (public domain) ontologies evolve the press.net ontology can be
>>> modified accordingly with respect to the public domain ontologies
>>> while not breaking the contracts of those clients bound to the
>>> press.net ontology.  This is good practice in my opinion.
>> 
>> This looks like a redundant cycle to me.
>> 
>>> 
>>> We are considering dropping the skos inheritance altogether, as skos
>>> is particularly cumbersome around inverseOf properties and their own
>>> ancestors resulting in n*n*8 statement chains being inferred from a
>>> n-depth classification scheme - (using pns:subClassificationOf
>>> subPropertyOf skos:narrower)
>> 
>> Please show me the added value of the majority of the term definitions of
>> the press.net ontology.
>> 
>> Cheers,
>> 
>> 
>> Bo
>> 
>> 
>> [1] https://github.com/moustaki/motools/tree/master/event
>> 
>> 
>

Received on Friday, 9 September 2011 21:07:55 UTC