Typing: was Re: DBpedia as possible project

Hi Lars,

On 3 Nov 2010, at 1:55 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>>> I think "instance of"/"type of" is one of the most misused statements
>>> at all.
> 
>> Maybe so, but sometimes where it gets "misused" is at or across
>> context boundaries, isn't it?
> 
> Yes.
> 
>> Honestly, this is something that I struggle with from time to time
>> too, but basically, to me at least, instance of/type of just means
>> instance A *may* share or include properties associated with type X.
> [...]
>> What would you say was "correct" usage? Is it an absolute or a
>> contextually-bound statement?
> 
> In a perfect model it would be an absolute statement. A fact/statement
> which does not change.
> 
> Is Joe Cocker an instance of "plumber", "composer", or "musician"? In
> a better model these instance of statements would be modelled as
> associations where the mentioned topics would i.e. play the role
> "occupation".

This is the point I was raising with my reply to Peter yesterday.  It's all well and good to say "oh, no.  That's not a type, it's a *role type*" because that's the gateway to starting to apply context to what we mean by the designated type name, but then what?  What have we really gained if we want to start discussing the properties of that role type in relation to the players?

Sure, we can (in TMDM) reify the association and start decorating it with occurrences, but I don't think that's the same thing as collecting the properties related to the role which apply to players of that role generally (if you follow me).  Sometimes it's hard, but sometimes things like qualifications, e.g. flight hours for pilots vs. flight hours in particular aircraft, are reasonable things to talk about.  You can do the latter via specific association reifications for each of the pilot-qualified-aircraft associations, but the former forms a more general characteristic that should be shared by all players of a specified role, whether they've been explicitly assigned or not.

Sure, you can argue that total flight hours is a dynamic property that would best be resolved by a query, but, with real data in the real world, that doesn't always work.  Most data of any value I've seen tends to include various levels of abstraction in the same data set (or union of available data sets), so saying it must be a derived property wouldn't tell you the whole story.

Going back to the astronaut example earlier, dogs, primates and pigs were all used in early spaceflight (but the pigs - while more human like in many areas - died when left on their backs, so primates were the next best choice).  Each of these could be said to have a number of flight hours total, but they would also be instances of more standard biological classifications.

This is the root of my earlier definition of type as a collection of properties which *may* be applied to something so that you can start talking about them as a group.  It doesn't mean that flight-hours should be a property/occurrence type/whatever of people, dogs, pigs and primates, but being able to classify "pilots" or "astronauts" on the basis of common properties is a very useful thing to do.

I actually did some googling earlier, but what does a role type really *mean*?  I agree it's useful to identify and classify players of an association, but what happens when we want to start talking about that role type?  I didn't spend hours looking, but I didn't really see any examples that looked at information through both the perspective of types and role types similar to the example above.

I'm sure they exist, so pointers would be most welcome if you have any. :)

> In natural language we say often "something" is an instance of
> "something else", but in our models we could be more exact (if we
> want). Am I an instance of "child"? I herewith confess that I have
> parents. ;)


We also need a way of defining what we mean by "exact" here.  I see type systems as sort of Venn diagram overlays on any information set - again defined by a set of common properties - that can't practically be as rigid as everyone would like them to be because, to quote Murray, "it might break their toys" or not quite fit nicely into a modeling context (I love that quote, BTW).

Sometimes the classifications are temporal, sometimes they're physical, sometimes there based on shared perspectives, communities or other forms of context.  Saying we must choose one or the other seriously limits the things we can do with any information set.  I just think that being exact requires a bit more than creating a distinction between things like "type" and "role type" and that there's a good bit of work to be done (and mistakes to be made) trying to nail down exactly what this sort of thing looks like.

Thanks for your thoughts.

Cheers,

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org