================================================================ Section 0. Contact and confidentiality ================================================================ Contact e-mail:
Irene Celino <irene DOT celino AT cefriel DOT it> (main contact)
Emanuele Della Valle <emanuele DOT dellavalle AT cefriel DOT it>
Francesco Corcoglioniti <francesco DOT corcoglioniti AT cefriel DOT it>
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:
- the generation of pages: what information about a resource should bedisplayed and how it should be presented to the users;
the navigational paths: how a user can navigate through resources by exploiting the links between resources; STAR:dust can be used for designing pre-defined paths to be followed across information;
- multiple views on information: the model allows the definition of different "travels" across resources, e.g. taking into account users' profiles or preferences.
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, http://seip.cefriel.it) 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 http://seip.cefriel.it); 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 http://seip.cefriel.it. Some publications about STAR:dust and SOIP-F are available on the web at http://swa.cefriel.it/Publications#soip-f_publications.
================================================================
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:
- skos:related is used to define the connection between the current resource and other resources that are somehow similar or on the same subject;
- skos:broader/skos:narrower are used to represent the connections between the current resource and those resources that are at a higher/lower level of complexity;
- skos:relatedPartOf (part-of relation) represents the containment connection between the current resource and its parts (e.g., the relation between a section and its sub-sections);
- skos:Concept is used to represent the "element", i.e. every "place" where it is possible to go and the portion of information that is relevant for the navigation.
Access model:
- axs:Home is the landmark indication, i.e. the denotation of specific resources that can be taken as reference for navigation;
- axs:prev/axs:next relations are the connections between the current resource and those resources that are immediately before/after in a specific path;
- axs:up/axs:down relations are the connections between the current resource and those resources that are immediately above/below in a specific ordered list or hierarchy.
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:
<owl:ObjectProperty rdf:ID="next"> <rdfs:label>next</rdfs:label> <rdfs:comment>link to the subsequent resource</rdfs:comment> <rdf:type rdf:resource="&owl;TransitiveProperty"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="prev"> <owl:inverseOf rdf:resource="#next"/> <rdfs:label>previous</rdfs:label> <rdfs:comment>link to the previous resource</rdfs:comment> </owl:ObjectProperty>
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 (http://webode.dia.fi.upm.es/Asun/SSS97.ps) 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" (http://www.w3.org/TR/swbp-thesaurus-pubguide/) and the "SKOS Core Guide" (http://www.w3.org/TR/swbp-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 http://swa.cefriel.it/Publications#soip-f_publications.
Some SOIP-F implementations are:
- Semantic-based Healthcare Information Portal
It is a Semantic Navigation engine built upon the STAR:dust model with the aim of providing General Practitioners with a system to search and navigate medical literature by leveraging on the semantics of the medical articles, expressed by a medical ontology. We have two different implementations, one developed for the COCOON project (FP6-507126, http://seip.cefriel.it/sir-demo), which uses a conceptual indexing engine and a medical ontology provided by the TeSSI suite produced by L&C, and another one (http://seip.cefriel.it/ship) that uses PubMed bibliographic references as content source and MeSH taxonomy as domain ontology.
- Virtual Museum of Contemporary Art portal It aggregates data (in Italian) about artworks and artists from different real museums, letting virtual visitors travel across resources with different "vehicles": a thematic trail vehicle, that offers a generic view on information, letting users to have a guided journey across artworks of a particular artistic movement or period, and a detailed investigation vehicle, that offers a specific view on information, by giving details about single resources (e.g., the work of a particular artist).
- Semantic Web Virtual Lesson It's a portal built as a unifying view on different material taken from some presentations about fundamentals, technologies and applications of Semantic Web; it allows end-users to move from a presentation to another and from a lecturer to another just following links to semantically related slides, as if it was a single lesson.
================================================================ 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.
- Mapping between domain ontology and navigation model
if an Artist painted an Artwork --> Artist skos:relatedHasPart Artwork
if a Chapter is about an Artist and describes an Artwork --> Chapter skos:related Artist, Chapter skos:related Artwork
- Mapping between domain ontology and access model
if a ThematicTrail contains a Chapter -->
ThematicTrail axs:down Chapter, Chapter axs:up ThematicTrail
if Chapter-1 is before Chapter-2 --> Chapter-1 axs:next Chapter-2, Chapter-2 axs:prev Chapter-1
- Mapping between domain ontology and presentation model
if an Artwork is represented by an Image --> Artwork skos:symbol Image
if an Artist is described by his Biography --> Artist pres:hasFullText Biography
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 http://seip.cefriel.it for more information. Details about SOIP-F can be also found in some publications about its implementation, available on-line at http://swa.cefriel.it/Publications#soip-f_publications.