Re: Press.net News Ontology

I agree with the principle of more sharing, and reusing existing properties
and classes.  However you must proceed with caution.

Anyone who chooses to do so should be aware that the semantics of the thing
you are reusing can change from under you.  To wit, in 2008 the meaning of
skos:broader changed, but the URI stayed the same.  It used to be
transitive, but no longer is.  You need to carefully assess how your
ontology is going to be used, and how certain you are that the things you
are re-using will remain stable.

At the 2010 SemTech Conference I gave a talk on this topic:  Avoiding a
Semantic Web Roadblock: URI Management and Ontology
Evolution<http://www.slideshare.net/UscholdM/uschold-michael-semanticwebroadblock>.
If you are interested in summaries of email discussions on this and related
topics see:

   1. Versioning and
URIs<http://ontologydesignpatterns.org/wiki/Community:Versioning_and_URIs>
   : General Issue: When and whether to make new URIs for different versions
   of things.
   2. Proliferation of URIs, Managing
Coreference<http://ontologydesignpatterns.org/wiki/Community:Proliferation_of_URIs%2C_Managing_Coreference>
   : General Issue: There are some negative consequences to the current
   proliferation of new URIs being minted for the same things. The issue is how
   to avoid or manage this.
   3. Overloading OWL
sameAs<http://ontologydesignpatterns.org/wiki/Community:Overloading_OWL_sameAs>
   : General Issue: owl:sameAs is being used in the linked data community in
   a way that is inconsistent with its semantics.

Michael

On Fri, Sep 9, 2011 at 2:06 PM, Tim Hodson <hodson.tim@gmail.com> wrote:

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


-- 
Michael Uschold, PhD
   Senior Ontology Consultant, Semantic Arts
   LinkedIn: http://tr.im/limfu
   Skype, Twitter: UscholdM