This is an archive of an inactive wiki and cannot be modified.

Section 0. Contact and confidentiality
Contact e-mail:

Do you mind your use case being made public on the working group website and documents?

We'd be very glad if you'll publish our use case.

Section 1. Application
  1.1. What is the title of the application? 

The STAR:dust conceptual model: Semantic Travel Across Resources (STAR) with the aim of designing unified support tools (dust) to help travelers in their navigation

  1.2. What is the general purpose of the application? 

       What services does it provide to the end-user?

STAR:dust is a conceptual model aimed at designing and specifying the navigation, i.e. the "travel" that web users undertake while surfing through resources. It provides a thorough conceptualization that can be used as "application ontology" (in a MDA approach) for software tools (called "vehicles" in the metaphor of travel) that support the navigation and the presentation of resources.

 *1.3. Provide some examples of the functionality of the application. Try to illustrate all of the functionalities in which the vocabulary(ies) and/or vocabulary mappings are involved.

The STAR:dust model is used to design:

  1.4. What is the architecture of the application? 

       What are the main components? 

       Are the components and/or the data distributed across a network, or across the Web?

STAR:dust is the top-level conceptual model; the Travel model comprises three ontologies for navigation, access and presentation (see section 2). Any application that makes use of the STAR:dust model (see SOIP-F, uses a mapping approach to put in relation the travel model with the domain-specific model, i.e. the knowledge base containing the resources to be navigated, potentially expressed with regards to a domain-specific ontology (see section 3).

  1.5. Briefly describe any special strategy involved in the processing of user actions, e.g. query expansion using the vocabulary structure.

The links and pages generation are based on the mappings between the travel model and the domain-specific ontology; moreover, this can be enhanced by exploiting the semantic descriptions of the users' profiles and preferences.

  1.6. Are the functionalities associated with the controlled vocabulary(ies) integrated in any way with functionalities provided by other means? (For example, search and browse using a structured vocabulary might be integrated with free-text searching and/or some sort of social bookmarking or recommender system.)

We designed the STAR:dust model with the aim of enabling the implementation of model-driven applications that takes STAR:dust as "application ontology" (see SOIP-F at; this approach makes the application capable to generate the pages starting from the model.

  1.7. Any additional information, references and/or hyperlinks. 

SOIP-F (Semantic Organizational Information Portal framework) is a framework for building semantic portals enhanced by semantics. Several domain specific portals were built on top of SOIP-F and are available on-line and listed on the web at Some publications about STAR:dust and SOIP-F are available on the web at

Section 2. Vocabulary(ies)
  2.1. What is the title of the vocabulary? If you're describing multiple vocabularies, please provide as many titles as you can.

The top-level vocabulary is the STAR:dust conceptual model. The Travel model is the main vocabulary that is made up of three parts: the navigation model, the access model and the presentation model.

  2.2. Briefly describe the general characteristics of the vocabulary, e.g. scope, size...

The STAR:dust model is made up of the main seven primitives (Vehicle, Traveler, TravelType, HyperEnvironment, TravelModel, TravelObject and Mapping) and their relations. The three parts of the Travel model are three ontologies, partially defined ad hoc (e.g., most of the access model) and partially referring to shared and wide-spread models like SKOS and Dublin Core vocabulary.

However, each application based on STAR:dust will define and exploit mappings between the Travel model and the domain-specific ontologies. In our running applications, each portals has its own ontology and we experimented both limited and very huge ontologies (with millions of triples).

  2.3. In which language(s) is the vocabulary provided? 

       In the case of partial translations, how complete are these? 

STAR:dust and the Travel model are not multilingual, since they are used by the software (and they don't have to be visualized to the users). The domain-specific ontologies however can have labels in multiple languages to allow the display of information in the language of the user.

 *2.4. Please provide below some extracts from the vocabulary. Use the layout or presentation format that you would normally provide for the users of the vocabulary. Please ensure that the extracts you provide illustrate all of the features of the vocabulary.

Navigation model:

Access model:

Presentation model:

It contains a lot of classes and properties to model all the characteristics of knowledge visualization; the resulting ontology is composed of both existing primitives coming from popular and shared models (e.g., properties like dc:title, dcterms:image or skos:symbol, skos:prefLabel and skos:altLabel) and other building blocks we modeled explicitly.

  2.5. Describe the structure of the vocabulary. 

       What are the main building blocks? 

       What types of relationship are used? If you can, provide examples by referring to the extracts given in paragraph 2.4.

For example, in the presentation model, we describe the different options to visualize a long text: the text could be displayed in full at the center of the page; or it could be abbreviated (the first few words followed by dots) leaving the rest of the text "behind" a hyperlink or a button; finally, it could be inserted in a box or frame with scrollbars, in order to present all the details without taking up too much space. To this end, we modeled the property pres:hasText and its sub-properties pres:hasFullText, pres:hasShortText and pres:hasSlidebarText.

  2.6. Is a machine-readable representation of the vocabulary already available (e.g. as an XML document)? If so, we would be grateful if you could provide some example data or point us to a hyperlink.

The Travel model is modeled in RDF/OWL and all the domain ontologies used in running applications were also expressed in RDF/OWL. Some sample triples from the access ontology of the Travel model:

  2.7. Are any software applications used to create and/or maintain the vocabulary? 

       Are there any features which these software applications currently lack which are required by your use case?

No, the vocabulary maintenance is performed through an RDF/SKOS/OWL editor.

  2.8. If a database application is used to store and/or manage the vocabulary, how is the database structured? Illustration by means of some table sample is welcome.

We use Sesame repositories with a MySQL backend to store the knowledge bases in RDF format using Sesame pre-defined structures (therefore we didn't need to define any table structure).

  2.9. Were any published standards, textbooks or written guidelines followed during the design and construction of the vocabulary? 
       Did you decide to diverge from their recommendations in any way, and if so, how and why?

Generally, we use Methontology ( to build OWL ontologies. In the modeling of our SKOS-based ontologies, we made also use of the "Quick Guide to Publishing a Thesaurus on the Semantic Web" ( and the "SKOS Core Guide" (

  2.10. How are changes to the vocabulary managed?

The vocabulary maintenance is performed manually.

  2.11. Any additional information, references and/or hyperlinks. 

Some publications about STAR:dust and SOIP-F are available on the web at

Some SOIP-F implementations are:

Section 3. Vocabulary Mappings
  3.1. Which vocabularies are you linking/mapping from/to?

We use a mapping approach to put in relation the Travel model with the domain-specific ontology to build the single domain specific application. For example, in the virtual museum portal, we map between the navigation/access/presentation models and the ontology of art and artists.

 *3.2. Please provide below some extracts from the mappings or links between the vocabularies. Use the layout or presentation format that you would normally provide for the users of the mappings. Please ensure that the examples you provide illustrate all of the different types of mapping or link.

We give hereafter some simple examples for the Virtual Museum portal.

  3.3. Describe the different types of mapping used, with reference to the examples given in paragraph 3.2.

We use different kinds of mapping between the Travel model and the domain ontology; for the simplest cases, we use SPARQL CONSTRUCT queries to perform those mappings.

Of course, within the domain ontology, we make use of hyperonymy/hyponymy, meronymy/holonymy (part-of relation), multiple wordings (homonymy/pseudonymy/synonymy) and generic semantic relationship whenever needed.

  3.4. Any additional information, references and/or hyperlinks. 

See for more information. Details about SOIP-F can be also found in some publications about its implementation, available on-line at