Re: Intranet ontology?

Alex,

A thought just occurred to me that might explain why there aren't any
"intranet" ontologies.

When people write ontologies they are focussed on describing the types,
attributes and relationships of things. Types — person, company, city,
document, site, role, router, cable and so on. Attributes — name, date of
birth. Relationships — created by, owned by, part of, born in. (Of course,
type is just an attribute too.)

The intranet is just where the data happens to be right now.

We have done many consulting engagements helping teams work through their
modelling and, often, they find that as they explore their data they find
that some is internal only (intranet), some wants to be shared with
partners (extranet) and some could valuably be published publicly
(internet).

Modelling using the existing, more and more widely accepted, ontologies
such as dublin core gives you the freedom to describe entities consistently
across that spectrum of sharing.

hope that helps

rob


On Tue, Feb 21, 2012 at 4:02 AM, Alexander Johannesen <
alexander.johannesen@gmail.com> wrote:

> Hi Tim,
>
> Thanks for your reply, and I appreciate the sentiment and the
> pointers. I've been doing SemWeb stuff for almost 15 years, and have
> written a couple of inference engines on top of resolvers to create
> complex mixed models, so all of that is fine, and I understand and
> accept that no other model is going to work on the scale of the web
> (I'm a die-hard RESTafarian).
>
> But epistemology is my game, and IMHO the authorship of a single
> ontology has a tendency to give a more precise shorter answer over
> large sets of data than a host of several small, especially
> considering the issue of ontology impedance which still isn't anywhere
> near being solved in a generic way, even though W3C tries very hard to
> consolidate. (I tried for many years to involve the library sector in
> this debate) I recently had to clean up someone else's mess because
> people treated dc:title as foaf:title. :)
>
> > If this sounds like a mess, it is in fact the pattern which
> > actually is optimal
>
> Hmm, I wouldn't call it optimal, but certainly my best option. When
> you accept REST, you are making compromises to your ideal solution for
> What Works [TM], and I'm all down with that.
>
> > I have written this up  in http://www.w3.org/DesignIssues/Fractal.html
> > and specifically http://www.w3.org/DesignIssues/Fractal.html#TCO
>
> I can't shake the feeling that there's a big assumption here that
> other people are creating models that a) are correct and b) agrees
> with you and c) semantically fits my data (or vice versa)? I
> understand what you're saying, and I think in an ideal world you're
> probably right (and it's a great principle to follow, and I've often
> taught this point, especially to enterprise environments), I just
> don't think I can agree that this is actually how it happens
> (depending on the need for precision). Shared and mixed ontologies
> will always be tied to the quality of modelling within them - even the
> tiniest little thing! - and the semantic impedance between them,
> rather than it being done at all. (And the difficulty of getting these
> things wrong might in itself provide an answer to why I can't seem to
> find many Intranet ontologies out there) I can also make a case that a
> mixed model might be the very thing that guarantees you a future
> failure given certain contexts, but I take your point.
>
> > I hope that helps you hit a happy balance between build and buy,
> > and adjust it with time as necessary.
>
> I'll probably mix and edit a few good ontologies, and define a fork of
> them as its own ontology, although the Gist ontology looks like a good
> upper / mid-ontology for it which I can extend. I just thought there'd
> be more in that space. :)
>
>
> Kind regards,
>
> Alex
> --
>  Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
> --- http://shelter.nu/blog/ ----------------------------------------------
> ------------------ http://www.google.com/profiles/alexander.johannesen ---
>