SKOS Use Case: STAR:dust

| ================================================================
| Section 0. Contact and confidentiality
| ================================================================
| 
| Contact e-mail:
Irene Celino irene.celino@cefriel.it  (main contact)
Emanuele Della Valle emanuele.dellavalle@cefriel.it
Francesco Corcoglioniti francesco.corcoglioniti@cefriel.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
| ================================================================
| 
| In this section we ask you to provide some information about the
| application for which the vocabulary(ies) and or vocabulary mappings
are
| being used.
| 
| Please note:
|  -- If your use case does not involve any specific application, but
| consists rather in the description of a specific vocabulary, skip
straight
| to Section 2.
|  -- If your application makes use of links between different
vocabularies,
| do not forget to fill in Section 3!
| 
|   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 be
displayed 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)
| ================================================================
| 
| In this section we ask you to provide some information about the
| vocabulary or vocabularies you would like to be able to represent
using
| SKOS.
| 
| Please note:
|  -- If you have multiple vocabularies to describe, you may repeat this
| section for each one individually or you may provide a single
description
| that encompasses all of your vocabularies.
|  -- If your use case describes a generic application of one or more
| vocabularies and/or vocabulary mappings, you may skip this section.
|  -- If your vocabulary case contains cross-vocabulary links (between
the
| vocabularies you presented or to external vocabularies), please fill
in
| section 3!
| 
|   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
| ================================================================
| 
| In this section we ask you to provide some information about the
mappings
| or links between vocabularies you would like to be able to represent
using
| SKOS.
| 
| Please note:
|  -- If your use case does not involve vocabulary mappings or links,
you
| may skip this section!
| 
|   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.

Irene Celino
CEFRIEL Politecnico di Milano
Via Fucini, 2 - 20133 Milano (Italy)
phone: +39 0223954266
fax:   +39 0223954466
email: Irene.Celino@cefriel.it
web:   http://swa.cefriel.it

Received on Friday, 12 January 2007 16:44:54 UTC