Handling Occurrences in Wandora - How ?

[athanassios]

Hi, I am trying to import the following occurrence item from Ontopia - TapsasConcerts.xtm that is converted to xtm v.2 first
topic id="id10">
<subjectIdentifier href="http://psi.ontopedia.net/Choir"></subjectIdentifier>
<name>
<type>
<topicRef href="#id411"></topicRef>
</type>
<value>Kor</value>
</name>
<name>
<value>Choir</value>
</name>
<occurrence>
<type>
<topicRef href="#id38"></topicRef>
</type>
<resourceRef href="http://www.kanzaki.com/ns/music#Chorus"></resourceRef>
</occurrence>
<occurrence>
<type>
<topicRef href="#id8"></topicRef>
</type>
<resourceRef href="http://en.wikipedia.org/wiki/Choir"></resourceRef>
</occurrence>
<occurrence>
<type>
<topicRef href="#id36"></topicRef>
</type>
<resourceData>A musical ensemble of singers.</resourceData>
</occurrence>
</topic>

You will notice that it has two external information resources declared with "resourceRef" element type and an internal one declared with the "resourceData" element type.

While importing Wandora reports that it converts the "resourceRef" occurrences to association !!!

<topic id="topic2158">
<subjectIdentifier href="http://psi.ontopedia.net/Choir"/>
<name>
<value>Choir</value>
<variant>
<scope>
<topicRef href="#topic2243"/>
</scope>
<resourceData>Kor</resourceData>
</variant>
</name>
<occurrence>
<type>
<topicRef href="#topic2143"/>
</type>
<scope>
<topicRef href="#topic2133"/>
</scope>
<resourceData>A musical ensemble of singers.</resourceData>
</occurrence>
</topic>

The two missing occurrences are converted to associations types "Used for" and "Web page" with wandora role types "occurrenceroletopic" and "occurrencerolereference" and for example in one instance with topicRefs "Choir" and "http://www.kanzaki.com/ns/music#Chorus" respectively.

My first question is whether there is any way to import resourceRef occurences in Wandora as they appear in xtm v2.0 ?

My second question is whether it is possible to manually handle or create resourceRef occurences with the Wandora user interface ? This is what I have tried so far.

From the traditional topic panel. I am doing a right click on the occurrences then I click Add occurrence... on the pop-up window, then I select the occurrence type either default or some other topic and I press OK. But nothing happens unless you have defined a scope and you have entered some data !!!

Therefore you have to follow an alternative route, right click on topic, select occurrences, select make occurrence with base name and you MUST select both occurrence type and scope before it is displayed on the topic panel.

But in that case the occurrence that is created is using the resourceData element see above.

The question remains, is it possible to handle resourceRef elements with Wandora, if no why is that ?

Thank you very much for you time and patience.

[akivela]

Hi Athanassios

Thanks for using Wandora. Unfortunately Wandora's topic map model is not complete. Most notable differences are described in [1] and reference occurrences are one of those missing features. To overcome the lacking feature, Wandora transforms -- as you have noticed -- reference occurrences into topics and places the reference occurrence into the topic as subject locator. Wandora also creates an association between the created occurrence topic and the occurrence carrier topic. This transformation pattern dates back to our early Wandora projects and has been dragged to the current Wandora release.

I suppose a better (or at least an alternative) transformation would be to transform reference occurrences to resource data occurrences. I think, I'll look at this change (feature addition) to the next Wandora version. Then Wandora user could choose whether to transform reference occurrences to topics and associations or resource data occurrences.

Wandora's topic map model requires a single type and a single scope for occurrences also. Also, a topic can contain only one occurrence per type and scope.

If you want to use occurrences as URL stores in Wandora, you have to use resource data occurrences. If you choose this path, notice limitations described above. Or, you could transform URLs to true topics and subject locators. This is something Wandora does automatically when importing topic map serializations. Also, this path enables you to add some additional information to URL topics.

Kind Regards,
Aki / Wandora Team

[1] http://www.wandora.org/wandora/wiki/ind ... Topic_Maps

[athanassios]

Hi Aki, I am trying to absorb the theory behind the topic maps. It is only very recently that I have started working with this technology. Therefore as an exercise I will make an attempt to clarify the concepts. You mentioned that Wandora transforms reference occurrences (i.e. external occurrences) into topics. Is not that reification, where you turn the specific occurrence to a topic so you can add assertions, in our case association statements ? Apart from that, I think what Wandora does with external occurrences breaks the separation of the Topic Map (ontology) layer from the information resources layer. Isn't that the reason that they have two concepts in the model to describe relationships: associations for topic to topic relationships, and occurrences for topic to information resource relationships ?

The second, not implemented, transformation you are suggesting is to turn an external occurrence (resourceRef element) into an internal occurrence and set the [datatype] property of the resourceData element to e.g. "http://www.w3.org/TR/xmlschema-2/#anyURI". Am I right ?

What I am trying to understand here is the logic to have two elements (resourceRef, resourceData) to address an information resource. Perhaps this is similar to the reason that they have two identifiers (SL, SI) to identify topics. They make clear that resourceRef ***refers to*** an information resource, while resourceData ***represents*** an information resource embedded in the topic map.

I will stop here, because the [scope] concept opens a big discussion. From the messages we exchanged it has not been clear whether Wandora limitations are due to complexities on the programming side or due to specific implementation logic that you put in the system.

Generally speaking I am given the impression, that topic maps technology is left a bit on the border. There are not many tutorials and examples around to clarify the really powerful concepts embodied in that data model. I have not found also many papers discussing the relationship of topic map data model to the enhanced entity relationship (EER) data model. An excellent comparison to the RDF/OWL model is given by Garshol (Living with topic maps and RDF). Please do point me to more resources comparing data models.

[akivela]

Hi Athanassios

Wandora transforms a reference occurrence to a topic and places the reference (URI) into the created topic as a subject locator. Yes, this transformation is a reification and allows topic map designer to create associations that address the reified occurrence-topic. As the subject locator of the reified topic is still the original occurrence URI, I don't see this behavior breaks the separation of topic map layer and the information resources layer. However, in general Wandora really does store occurrence resources in the topic map (as it supports only resource data occurrences) and this can be seen as a weakness if your aim is to keep occurrence resources separated from the topic map. But, in case of Wandora application, the picture isn't that clear as Wandora offers the user some tools that assume the resource data occurrence string is an URI. For example, occurrence download tool is such a tool.

About the second, not implemented transformation. Well, Wandora doesn't support datatypes in resource data occurrences, I am afraid. All occurrences in Wandora are just plain strings. But otherwise you got it right.

Exactly, resourceData *represents* the information resource while resourceRef *refers to* the information resource. And Wandora thinks (at the moment) that it is better to refer the information resource using topic's subject locator than the resourceRef occurrence.

Wandora's limitations are due to historical events; once we implemented the topic map engine we thought that this is sufficient implementation level and we have changed the engine very little since then. Ok, we have written a complete topic map engine since then but never integrated that to Wandora.

I am sad to say that topic maps haven't gained the popularity they deserve but don't see a major problem there. Popularity comes if it comes. And speaking a minor language myself, I don't see why everyone should speak same language.

Kind Regards,
Aki / Wandora Team

[athanassios]

Hi Aki,
I have spent some time reading about RDF/OWL - Topic Map notions of critical concepts such as INFORMATION RESOURCE! I have just realized that W3C people have elevated the meaning of this concept to include EVERY-THING, but that is not the case in the topic-map community! On the other hand I have noticed that both communities are using the PROPERTY notion which is a fundamental concept in philosophy, logic, mathematics, computer science. RDF/OWL is using (object property, data property, annotation property). Topic map is using names and occurrences. This is exactly the point that my brain has been boiling for days. The reason is simple, these properties of a subject/object are in fact concepts and they have their own domain of values. For example: (Person-->Athanassios, has a, height-->185). Athanassios is an instance of Person and 185 is an instance of height and 'has a' is some relationship/association type. It follows easily that you can replace every occurrence with an association and resource data become instances of a class (topics of a topic type). I understand that this may not be practical in terms of current topic map representations but provides a uniform way to deal with associations-relationships between everything. Then you can treat everything the same way on a graph structure.

In terms of the representation layers, currently the semantic web is mostly characterized I think as a linked-data graph. There are URIs of **information resources**, I am viewing it as pointers on data resources. Therefore we have two layers, the digital data resources layer and the interconnected pointers (URIs) layer. What I believe we are still missing here is the interconnected concept layer or else the links between domains of knowledge. Concepts that characterize a domain and that are defined/described by URIs are connected to, generate, data resources (instances). The relationship between the concepts on any two different domains reflect the relationship between the data resources.

I have expanded a bit on your view of turning resource references to topics. I plan to create graphs that explain these ideas above, but I need to have the edges labeled with the association type is there any way to do that in Wandora ?

I also have plans of creating topic map templates (schemas) on specific knowledge domains e.g. informatics and then connecting there my bookmark collection......

[akivela]

Hi Athanassios

You are surely digging deep here

In my opinion properties in RDF are very similar to occurrences in Topic Maps. Borrowing your example, it is easy to set up a triplet

<Athanassios> <has-height> "185"

where <Athanassios> and <has-height> are resources i.e. concepts but "185" is a literal and thus falls outside the resource-world. This triplet can be expressed in Topic Maps by attaching a resource-data occurrence "185" to a topic <Athanassios> with a type <has-height>. Now, if you reify the literal "185" to a concept <185> the RDF triplet changes to

<Athanassios> <has-height> <185>

and you can say more about the concept <185> using other triplets. Again, it is very easy to express this triplet using topic maps. Just create an association of type <has-height> and add topics <Athanassios> and <185> to the association as players with sufficient role types. Here is one of the biggest differences between RDF and Topic Maps: Association player has a role. Saying it more generally, in Topic Maps a graph edge has not only a type but edge also types nodes connected by the edge.

Whether to use "185" or <185> can be generalized to a decision of using literals or concepts (occurrences or topics). In my opinion this is a design question and there is no right answer.

What I have found quite an interesting design-pattern, is to use literals (occurrences) as storages of unstructured information where more explicit structures emerge. Say, you have a long text fragment, an article for example. The text fragment is stored in an occurrence. It contains relevant information related to topics that could be expressed using associations but you have not distilled associations out of the text yet -- or you might be uncertain about the distilled associations and want to keep the source of associations (the occurrence text) in safe. Both the unstructured text (the association source) and associations are expressed here using a single data format, Topic Maps. I feel this is a strength of the data format. I have a feeling that once you say *representation layers*, you actually refer this duality.

I share your vision that we are (mostly) missing links between domains of knowledge. Linked data effort is a manifestation of this vision. It promotes the use of well known vocabularities such as DBpedia (or should I say Wikipedia) and bridges vocabularities using simple similarity relations between concepts of different vocabularities. Linked data effort has it's weaknesses but in general they are doing an important job.

Yes, Wandora supports typed associations. Association creation is documented at [1]. Some additional information is available at [2]. Also, WandoraTV at [3] has three example videos with a title "Editing associations..." that review Wandora's association editing options.

Kind Regards,
Aki

[1] http://www.wandora.org/wandora/wiki/ind ... ssociation
[2] http://www.wandora.org/wandora/wiki/ind ... sociations
[3] http://www.wandora.net/wandora/tv/

[athanassios]

Hi Aki,
this time I have been searching back to the roots of semantic networks and concept maps and regarding the Roles notion in Topic Maps I have discovered a definition in the KL-ONE system. "a Generic RoleSet captures the notion that a given functional role of a Concept can be played by several different entities for just one individual. A RoleSet captures the commonality among a set of individual role players" (An Overview of the KL-ONE Knowledge Represenation System -Brachman and Schmolze 1985). The Role notion is also fundamental in many OOP analysis patterns. On the other hand yes we do have excellent concept vocabularies and there are many properties that describe relations between concepts and concepts. I think what we are missing here is standard semantic modeling based on already defined concepts. In terms of the implementation we are missing the schemas of common design patterns. Let me continue on the example we have been discussing above. We may define the classes for Athanassios, has-height, and 185 as Person-->Agent, attribute, quantity. First we do have to agree on definitions and Topic maps do have an advantage here as one can define topics with multiple subject identifiers i.e. use many vocabularies. Therefore if we use well defined topics, then it will be easier to do merging on the next stage. The next important step on exchanging data is what kind of associations (relations) we define. It has to become clear how exactly we represent nodes and edges on the graph. Normally edges are actions or attributes in the sense of concept categories (Aristotle, Kant, etc). Therefore continuing the example, we have attribute (agent, quantity) as an association type defined in the schema with roles agent and quantity, then I can have association instances of that type e.g. height(athanassios, q(i)). Where q(i)=quantity(value, unit) another association type with roles value and unit where 185 is of type value and cm is of type unit. Therefore relation between individuals become height(athanassios, quantity(185,cm)).

What is important for someone to realize here is that this is a long standing problem in AI concerning the modularity and generalization principles. On one hand you must have enough terms to describe your knowledge representation model (i.e. topic maps model) on the other hand you must be able to generalize on concepts and propositions about them using vocabulary that is not ambiguous and inference engine that can discover the patterns the user specifies.

Now I am not sure whether the idea I have is an outopia but I was thinking whether it is possible to provide users with schemas, either knowledge domain schemas and/or general analysis pattern schemas and see whether we can exchange data resources based on these common knowledge structures. Eventually these generic schemas will be standardized.

Saying that I will have to reply also about your example with the text fragment and the occurrence text. I suppose an alternative way to view that specific example will be to use a hyperlink that points to the text document stored somewhere in the network. Provided that you have a mechanism for permanent links you do not have to keep data embedded inside the topic map. Which gives me the idea, that every data source may well become hyperlinked through a database. For example continuing the example above the height(athanassios, quantity(185,cm)) can become height(athanassios, quantity((http://athanassios.gr/fetch.asp?query),cm)). Where the topic valueX has a subject locator (http://athanassios.gr/fetch.asp?query).

As a conclusion I am referring to the duality as you call it in your reply as the concept layer which is purely the semantics of the knowledge representation of some domain or some specific problem and the information resources, meaning digital data resources of any kind stored permanently or generated dynamically.

Now it is clear I suppose that I am thinking of the TAO model as the TA model

As they say in English
TA (thank you Aki for bearing my views

PS: Concerning the labels on the edges I am posting it separately

[vpieterse]

I got the following message when I tried to add an occurrence:

"Topic already contains occurrence with type XXX. Do you want to overwrite old occurrence?"

My answer is "NO - A want to add it i.e. keep both!" But I cannot do that.

I think that this feature of Wandora is not implementing the idea of occurrences correctly. Currently it is possible to have multiple occurrences of any topic as long as they each have a unique type. But I think it should also be possible to have multiple occurrences of the same type for any given topic. The types of occurrences are used to classify the occurrences. The exact same thing (or slightly different versions of it) may be available for a given topic. For example when you have located a publication with scholar.google you can click on "All xx versions" to get a list of occurrences of the publication. They are certainly occurrences of the same type. The logical way to enter such information about a publication in a topic map would be to have multiple occurrences of the same type. It is very common to have more than one occurrence of anything you can think of.

Vreda

[akivela]

Hello Vreda

Yes, Wandora topic map model is limited if compared to the standard. And one limitation is that a topic can contain only one occurrence per type and scope. These limitations are discussed at http://www.wandora.org/wiki/Reduced_Topic_Maps .

One way to overcome the occurrence limitation is to use topics and associations instead. You can always create a topic for the occurrence and then associate it with the occurrence-carrier-topic. The topic and association solution also enables you to store more information into the context of occurrence-data, say a publication date, an extraction date, an url and a sample text (thinking of your scholar.google example). If you were using plain occurrences, you were forced to focus on only one information snippet.

Kind Regards,
Aki / Wandora Team

[vpieterse]

Aki

Thank you for your prompt response. I have now read about this and other limitations of Wandora wrt to the TM standard. I have to confess that I did not read it before. In my view it means that Wandora lacks essential ingredients that makes topic maps better than some of the other available technologies.

I assume that these design decisions are not likely to change in the near the future.

[aki]

Happy new year, Vreda

Unfortunately we have no plans to change Wandora's internal data model in near future.

However, as I wrote in my earlier reply, you can easily overcome the limitation by using topics/associations instead of occurrences.

Perhaps I could help you. Please, feel free to tell me more about your application/use scenario.

Kind regards, Aki / Wandora Team

[athanassios]

For newcomers and old visitors that have changed to the latest version of Wandora I think
this post will be highly relevant to solve any question that
they might have on how to treat occurrences in Wandora 2015-11-13.

I had to spend a day or two to figure out how to update my old "ltm" topic maps so that they are compatible with this new release of Wandora.

Hope that you find that useful.