Re: Press.net News Ontology

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.
But if this was the way domain experts worked then everyone would end
up doing things slightly differently in the same domain. 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.
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.

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 14:28:54 UTC