Re: Typing: was Re: DBpedia as possible project

Lars Heuer <[email protected]>
Newsgroups gmane.text.xml.xtm.general
Organization Semagia
Message-ID <[email protected]>
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? ;)

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

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

[...]
> 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.

[...]
> 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 used this example since I think someone could be a Playmate and an
astronaut at the same time).

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

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.