Re: Typing: was Re: DBpedia as possible project

Hi Lars,

On 3 Nov 2010, at 7:00 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> This is the point I was raising with my reply to Peter yesterday.
> 
> I am crawling slowly through this thread. :) Who expected that many
> reactions and subject shifts caused by a simple topic map
> announcement? ;)

Yeah, well.... you started the commentary, I just couldn't help jumping in... ;)

> 
> Found it: [1]
> 
>> 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?
> 
> We may have created a model which is less context-dependent, I'd
> think.
> 
> Maybe we just shifted the problem, though. (I'll come back to this
> later).
> 
> What you've gained if you use an type-instance relationship? The
> type-instance association is like any other association. You cannot do
> "more" with it, i.e. attaching additional properties to it without
> having reified it (in TMDM). In TMRM we have a predefined "isa" and
> "sub" relationship which may differ from TMDM since their
> representation is undefined (or map-specific). So, isa and sub may
> differ from relationships which are modelled more closely acc. to
> TMDM.
> 
> In several Topic Maps standards we have shortcuts for type-instance
> relationships (XTM, CTM, most likely TMQL) and people may be tempted
> to think that type-instance relationships aren't associations, but
> that's wrong
> 
>   john isa person.
> 
> becomes
> 
>   tmdm:type-instance(tmdm:instance: john, tmdm:type: person)
> 
> So, I don't see any advantage over a specialization if it comes to
> roles like "composer", "musician"
> 
> Given the shortcut, I see of course an advantage: It's simpler to ask
> for
> 
>      // musician
> 
> than
> 
>     //has-occupation [./occupation == musician]
> 
> (or whatever TMQL looks like at the moment, you may get the point ;))

...and that's all well and good when we're talking about types and role types as simply, and arguably, arbitrary tags for classification in their own right.

I totally get that isa is an association/relationship/link between two concepts.  Just because there's syntactic sugar to make it easier to define doesn't change things as you say.

As far as your example goes, there really isn't any difference--both are simply roles played in particular associations.  The main area where we're starting to drift is that I'm talking about the properties of the players, not the reified associations themselves.

> 
>> 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).
> 
> I don't know if I get that correctly (I am afraid I didn't). Do you
> propose that an instance should inherit all properties of the type?
> Like in OOP?

Not exactly, no.  That's why I kept saying "*may* share".  This follows on basic biological classification (as I understand it, anyway, not claiming to be a bioscientist) and OOP just borrowed some of the concepts in specialized ways that made sense for that domain.  What I mean is that a type name, as a classifier, "means" something in a given context.  That meaning is generally derived from whether or not thing A matches the set of criteria X, where A has zero or more characteristics within set X.

If I then say something like (using whatever formal mechanism exists) "all things which have these characteristics shall henceforth be called an X", I've associated (oops...) a set of classification (dare I say "identifying"?) properties with a name that I can henceforth use as a broad, sweeping generalization/classification when I trip over things on the street that have some, all or none of these properties to see what I can do with it.

I realize that this description may be getting a bit tedious, but please bear with me, because I think we aren't talking about the same things here.

Pass 1 of identifying whether thing T could be an X is whether they have the designated properties or not.  Pass 2 of identifying whether thing T could be an X is whether those properties' values are within the set of acceptable things that I think identify an X.

Where things get sticky is that because I may not have all of the information about thing T, someone can designate it as an X, and then, because within the bounds of my ontology or within a specific context, I have said that all X's are identified by a collected set of properties, I should have the property labels/roles/names available whenever I interact with instances of something designated as an X--regardless of any other designation it might have.

This can actually be related to the original merging discussion as follows (and trying to keep things simple):

Map A defines a thing of type X and it has properties {a, b, c}

Map B defines a thing of type Y and it has properties {a, b, d, e, f}

If I want to merge map A and map B based on things I know about the maps (magic), I might be able to say that the thing in map A is a "person" and the thing in map B is an "astronaut".  Using my out of band understanding of the information, I can claim with some amount of certainty that if  A.thing.a == B.thing.a && A.thing.b == B.thing.b then A.thing and B.thing refer to the same subject, but within different contexts, e.g. each map.  However, the subject has different properties in each context because my perspective and interest is different.

I don't want to lose this information, and I want to be able to infer things or know I have potential opportunities to enhance the information in the merged map in specific ways based on looking at things both as instances of type X and/or as instances of type Y.

> 
> [...]
>> 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.
> 
> These sort of things should belong to a schema, imo.

I'd agree with you 100%.  Schema, legend, ontology or whatever you want to call it, but that's exactly my point.  I'm trying to say that what most people think of as hard and fast, set in stone definitions of a type really shouldn't be treated that way.  The "schema" is the only way you can really tell people what you think is important enough about any subject to classify it in a particular way.

> 
> [...]
>> Sometimes the classifications are temporal, sometimes they're
>> physical, sometimes there based on shared perspectives, communities
>> or other forms of context.
> 
> That's definitely true and brings me back to the problem-shift I
> mentioned above. Even if I have specialized associations, they are
> still unconstrained. They are valid in all contexts. Due to the usage
> of scope I can limit their validity (later).
> 
> I can also add scope to type-instance relationships, but commonly they
> are unconstrained (and in RDF they are always unconstrained). So, the
> type-instance problem (or the "abuse" of type-instance relationships)
> might be more a problem of systems which do not support contexts.
> 
> To take an example from Sowa:
> 
>  a) tom isa person.
>  b) tom isa baby.
>  c) tom isa adult.
> 
> Only (a) is valid in all contexts, while (b) and (c) are context
> dependent since the topic "tom" cannot be a baby and an adult within
> the same context.

I get this, and that isn't the issue.  What I was trying to say earlier is that you could reify those particular associations as many times as you wanted and decorate the topics representing the associations, but you aren't actually applying properties to the role players themselves (nor should you be in this case).

If something is important enough to designate as a role type, then you might want to later start saying things about the topics that play that role using those sweeping generalizations I mentioned earlier.  Then you might want to classify them according to certain attributes you think should be common or criteria they should meet to be eligible to play those roles and then, suddenly, you end up with just a ordinary identifier used as a name for a collection of properties that smells, sounds, tastes and walks exactly like "ordinary" types that you might be using elsewhere.

Role types are types that are used in a particular context, but in most cases, the designation only goes that far.  They may, by accident or design, share an identifier that's used elsewhere as a normal type, but then that just proves that they're really just normal types so - except for within the context of the definition of the association type - the distinction really doesn't matter.  Roles played or as a collection of identifying characteristics, it's still just an everyday, garden-variety type.

> 
> (I used this example since I think someone could be a Playmate and an
> astronaut at the same time).

Me too.  Although, from some of the photos I've heard about *cough*, some sure must be because there seems to be a distinct absence of gravity hovering around particular areas of their bodies... ;)

> 
> [1]
> <http://www.infoloom.com/pipermail/topicmapmail/2010q4/008593.html>


Hopefully this makes more sense.

Cheers,

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