Property:LongDescription

From Odp

Jump to: navigation, search

Long Description. This property contains a longer description of the entity it refers to than is given in the property Description.

This is a property of type Text.


(previous 25) (next 25)

Pages using the property "LongDescription"

Showing 25 pages using this property.

A

Association Ontology +The Association Ontology combines features The Association Ontology combines features of the Similarity Ontology, the Review Ontology and DCMI Metadata Terms. The intend behind this ontology is to provide a mechanism to append (personal) association statements (sim:Association) to something by using the relation sim:association. This step of indirection is neccessary to enable: * reusable association statements and * voting, rating and reviewing of association statements in a specific context. Therefore, the sub class ao:LikeableAssociation was created, which combines the concepts of sim:Association and rev:Review. Simple voting (the "like button") can be realized by using the property ao:likeminded, which creates a relation between an association statement and an individuum (foaf:Agent). Ratings and reviews can be realized by using the features of the Review Ontology, e.g. rev:rating or rev:Feedback. To address associations of a specific domain, e.g. genre, mood or occasion, new sub properties based on dcterms:subject were created. These are: * ao:genre: a hook for genres descriptions of all kind, * ao:mood: a hook for mood descriptions and * ao:occasion: a hook for occasion descriptions. They are intendend to be an abstact and general hook into their specific domains (genre, mood, occasion). Furthermore, new, more specific sub properties based on these properties should be created to provide a hook in more specific domains, e.g. mo:genre for music genres/styles (this sub property relation isn't currently the case). To enable voting, rating and reviewing of a reusable association statements in a specific context, the property ao:included_association was created. By using this relation one can include a reusable association statement into another association statement (preferable based on ao:LikeableAssociation). Please have also a look at the example in this document, which illstrates this use case. document, which illstrates this use case.

C

CGI Simple Lithology 201001 +OWL ontology for categorization of rock ty OWL ontology for categorization of rock types. Class definitions derived from CGI SKOS vocabulary at https://www.seegrid.csiro.au/subversion/CGI_CDTGVocabulary/tags/SKOSVocabularies/SimpleLithology201001.rdf URI to identify ontology is urn:cgi:classifierScheme:CGI:LithologyOWL:201001 i:classifierScheme:CGI:LithologyOWL:201001
COMM - Core ontology for Multimedia Annotation +In order to retrieve and reuse non-textual In order to retrieve and reuse non-textual media, media annotations must explain how a media object is composed of its parts and what the parts represent. Annotations need to link to background knowledge found in existing knowledge sources and to the creation and use of the media object. The representation and understanding of such facets of the media semantics is made possible through a formal language and a corresponding ontology. COMM is based on a careful analysis of the requirements underlying the semantic representation of media objects. It goes beyond the capabilities of most semantic multimedia ontologies. COMM was built by re-engineering MPEG-7. It leverages components from the DOLCE foundational ontology to support conceptual clarity and soundness as well as extensibility towards new annotation requirements. ility towards new annotation requirements.
Chemical Compound and Chemical Functional Group Ontology +Functional groups are described by pattern Functional groups are described by patterns of atomic connectivity which exhibit characteristic chemical reactivity in compounds that contain them. Being able to identify such compounds is important to both synthetic and medicinal chemistry and for drug discovery. This collection of OWL ontologies makes possible the classification of compounds based on the presence of acyclic functional groups using an OWL reasoner. The presence of functional group is inferred from the chemical structure, defined in terms of atoms and the bonds they share. n terms of atoms and the bonds they share.
Cognitive Characteristics Ontology +The Cognitive Characteristics Ontology inc The Cognitive Characteristics Ontology includes two opportunities to model cognitive patterns. The first one is the representation of cognitive characteristics by using the semantic relation cco:cognitive_characteristic or better its more specialised sub properties (see graphic cco:cognitive_characteristic property as graph with relations) to associate the topics of the cognitive patterns to the users. The second opportunity is the property-oriented context reification of cco:cognitive_characteristic, cco:CognitiveCharacteristic, which is a general multiple purpose cognitive characteristic concept to describe cognitive patterns more in detail for a specific user or user group. As one can see in graphic cco:CognitiveCharacteristic concept as graph with relations, the specialised sub properties of cco:cognitive_characteristic, the cognitive patterns, currently are * interest (cco:interest), that means, a certain area of interest or preference, which is equivalent to foaf:topic_interest, * compentence (cco:competence), that means, the compentence to (be able to) do or know something or * setting (cco:setting), often regarding a specific environment, e.g. an application. One can also refine the semantic relation of a competence association by using the sub properties of cco:competence, which are currently: * cco:skill: the ability or skill to (be able to) do something, e.g. to walk, to play the piano or to work in a team * cco:expertise: the knowledge or expertise in a certain domain or a specific topic, e.g. football, programming languages or music * cco:belief: an uncertain relation for competence representation, that means beliefs, persuasions or opinions, which can also be misconceptions One can see the second opportunity to model cognitive patterns, cco:CognitiveCharacteristic in graphic cco:CognitiveCharacteristic concept as simplified graph with relations. This concept can be used to associate any foaf:Agent instance to (a) cco:CognitiveCharacteristic instance(s) with help of the properties cco:habit and cco:agent. The topics of a cco:CognitiveCharacteristic instance are related to it by using the property cco:topic, so that a property chain of cco:habit and cco:topic will also direct to topics of a cognitive pattern of an user or user group. That means, a statement that is modelled with the simple semantic relation approach based on cco:cognitive_characteristic can also be represented by an instance of cco:CognitiveCharacteristic, which has a cco:agent or cco:habit, a cco:topic and a cco:characteristic relation. The last property in this row is used to associate the applied cognitive pattern relation (sub properties of cco:cognitive_characteristic). Different statistics can be made on cognitive characteristics. These are currently: * cco:overall_weight, which reflects the overall interest in a topic and should be different from the actual weight (associated by the property wo:weight) of a cognitive characteristic * cco:longest_duration, which is the longest continuous interval of attention for a cognitive pattern, e.g. for an interest, if it appears in the following years: 1990, 1991, 1995, 1996, 1997, 1998, 2001, then the longest duration is 4 years * cco:ultimative_duration, which is the overall duration of attention for a cognitive pattern, e.g. for an interest, if it appears in the following years: 1990, 1991, 1995, 1996, 1997, 1998, 2001, then the longest duration is 7 years Besides these statistics, one can also associate a concrete activity (by using the property cco:activity), to differentiate e.g. between football playing (topic = football; activity = playing) and football watching (topic = football; activity = watching), and further statistical items (by using the property cco:statistical_item) to a cognitive pattern description, which is itself also a sub class of scovo:Item. It is also important, to be able to describe dynamics of a cognitive characteristic. In the Cognitive Characteristics Ontology they can be described with help of the cco:CharacteristicDynamics concept, which is a sub class of wo:Weight, and can be related to a cco:CognitiveCharacteristic instance by using the property cco:characteristic_dynamics. Thereby, one can relate * concrete appear times (time instants or intervals, by using the property cco:appear_time), when a cognitive pattern gets attention by someone, or * an evidence description (by using the property cco:evidence), where this characteristic or dynamics was derived from. to a cco:CognitiveCharacteristic or cco:characteristic_dynamics instance. Due to the two modelling opportunities of cognitive pattern in the Cognotive Characteristics Ontology, there is a need for formal semantics to associate statements with a shortcut relation and instances of the reification class that belonging together or to infer such knowledge with a reasoning engine. The Property Reification Vocabulary fulfil these requirements. tion Vocabulary fulfil these requirements.
Counter Ontology +The Counter Ontology includes a general mu The Counter Ontology includes a general multiple purpose counter concept. This concept could be uses to associate any concept to a co:Counter instance(s) with the property co:counter or a specific sub property of it. The second property of co:Counter is co:count, which is a simple xsd:integer based datatype property. That means you could use this concept for things like for example play counter, skip counter or website hit counter. Furthermore, this ontology includes already a predefined property to associate event specific ( event:Event) counter to its related events (co:event_counter,), e.g. a co:ScrobbleEvent to scrobble something. This enables the opportunity to trace back all related events, which are responsible for a specific count. Of course, this is also possible with all other concepts ;) s also possible with all other concepts ;)

E

Emotional Knowledge Graph (EmoKG) +Interdisciplinary IoT and Emotion Knowledge Graph-Based Recommendation System to Boost Mental Health. Amelie Gyrard and Karima Boudaoud. MDPI Applied Sciences 2022. Special Issue Affective Computing and Recommender Systems.
Event Model F +Event-Model-F is a formal model of events Event-Model-F is a formal model of events designed to facilitate interoperability in distributed event-based systems. The model is based on the foundational ontology DOLCE+DnS Ultralite (DUL) and provides comprehensive support to represent time and space, objects and persons, as well as mereological, causal, and correlative relationships between events. In addition, the Event-Model-F provides a fexible means for event composition, modeling event causality and event correlation, and representing di�erent interpretations of the same event. The Event-Model-F is developed following the pattern-oriented approach of DUL, is modularized in di�erent ontologies, and can be easily extended by domain speci�c ontologies. ily extended by domain speci�c ontologies.

F

FIESTA-IoT +FIESTA-IoT ontology takes inspiration from FIESTA-IoT ontology takes inspiration from the well-known Noy et al. methodology for reusing and interconnecting existing ontologies. To bu0ild the ontology, we leverage a number of core concepts from various mainstream ontologies and taxonomies, such as Semantic Sensor Network (SSN), M3-lite (a lite version of M3 and also an outcome of this study), WGS84, IoT-lite, Time, and DUL. In addition, we also introduce a set of tools that aims to help external testbed adapt their respective datasets to the developed ontology. R. Agarwal, D. Fernandez, T. Elsaleh, A. Gyrard, J. Lanza, L. Sanchez, N. Georgantas, V. Issarny, "Unified IoT Ontology to Enable Interoperability and Federation of Testbeds", 3rd IEEE World Forum on IoT, pp. 70-75, Reston, USA, 12-14 December 2016. DOI: 10.1109/WF-IoT.2016.7845470, IEEE, HAL OI: 10.1109/WF-IoT.2016.7845470, IEEE, HAL
Foundational Model of Anatomy (FMA) +'''''What is the FMA Ontology?'''''The Fou '''''What is the FMA Ontology?'''''The Foundational Model of Anatomy Ontology '''(FMA''') is an evolving computer-based knowledge source for biomedical informatics; it is concerned with the representation of classes or types and relationships necessary for the symbolic representation of the phenotypic structure of the human body in a form that is understandable to humans and is also navigable, parseable and interpretable by machine-based systems. Specifically, the FMA is a domain ontology that represents a coherent body of explicit declarative knowledge about human anatomy. Its ontological framework can be applied and extended to all other species. The Foundational Model of Anatomy ontology is one of the information resources integrated in the distributed framework of the Anatomy Information System developed and maintained by the [http://sig.biostr.washington.edu/index.html Structural Informatics Group][http://sig.biostr.washington.edu/index.html ]at the University of Washington. '''''Purpose'''''The Foundational Model of Anatomy ontology makes available anatomical information in symbolic (non-graphical) form to knowledge modelers and other developers of applications for education, clinical medicine, electronic health record, biomedical research and all areas of health care delivery and management. The intent is to assure - through the FMA - consistency, and ultimately standards, in anatomical class representation. Thus, the FMA is a biomedical informatics resource for developing the anatomy content of applications that target specific user groups; the FMA as such, is not designed as an end-user application for anatomy students, teachers or any other particular user group. '''''Components'''''The Foundational Model of Anatomy ontology has four interrelated components: 1. '''Anatomy taxonomy (At)''',classifies anatomical entities according to the characteristics they share (genus) and by which they can be distinguished from one another (differentia)-designated in previous publications as the Anatomy ontology or '''Ao'''; 2. '''Anatomical Structural Abstraction (ASA)''',specifies the part-whole and spatial relationships that exist between the entities represented in '''At'''; 3.''' Anatomical Transformation Abstraction (ATA)''', specifies the morphological transformation of the entities represented in At during prenatal development and the postnatal life cycle; 4. '''Metaknowledge (Mk)''',specifies the principles, rules and definitions according to which classes and relationships in the other three components of FMA are represented. Thus, the Foundational Model of Anatomy ontology may be represented by the abstraction: <center>'''FMA = (At, ASA, ATA, Mk)'''</center> '''''Contents'''''The Foundational Model of Anatomy ontology contains approximately 75,000 classes and over 120,000 terms; over 2.1 million relationship instances from over 168 relationship types link the FMA’s classes into a coherent symbolic model. The FMA is one of the largest computer-based knowledge sources in the biomedical sciences. The most comprehensive component of the FMA is the Anatomy taxonomy ('''At'''). The dominant class in the At is '''Anatomical Structure'''. Anatomical structures include all material objects generated by the coordinated expression of groups of the organism’s own structural genes. Thus, they include biological macromolecules, cells and their parts, portions of tissues, organs and their parts, as well as organ systems and body parts (body regions). Macroscopic anatomical structures are most comprehensively represented, whereas biological molecules have been entered mainly to illustrate the structural continuum from major body parts, such as the thorax, to biological macromolecules, such as myosin. Portions of body substances, such as blood, CSF, intercellular matrix, and cytoplasm, are defined in terms of their relationship to anatomical structures, and so are spaces, surfaces, lines and points that are associated with anatomical structures. An objective of [http://sig.biostr.washington.edu/projects/fm/FME/aboutFME.html#conductedTour Foundational Model Explorer/Conducted Tour] is to give an appreciation of the classes that subsume all these diverse classes within a continuous taxonomy. Traditional sources do not include such a comprehensive taxonomy and do not explicitly define classes or types. Therefore we had to propose and define a number of classesor types of anatomical entities in the FMA for which there is no precedence in the traditional literature. There is an increasing correspondence between the FMA and traditional sources as one proceeds from the root of the '''At '''(Anatomical entity) toward the leaf classes of the FMA (e.g., heart, hepatocyte). For example, the FMA contains essentially all the terms of ''Terminologia'' ''Anatomica'' with an appropriate record of their derivation from this source. cord of their derivation from this source.

G

GUM-Space +A technical report of the structure of the GUM-Space ontology is available at: http://www.ontospace.uni-bremen.de/ontology/gum.html
GoodRelations +The GoodRelations ontology provides a conc The GoodRelations ontology provides a conceptual model for a consolidated view on commerce data on the Web, e.g., companies, store locations, offers, product descriptions, pricing, payment, shipment, and warranty information. Since its official release in August 2008, it has gained substantial popularity and is supported by e.g. Yahoo and BestBuy. At the time of writing, there are more than 1,5 million non-toy product model descriptions, 450k individual offers with price information, and 50 k company profiles available. In addition, the popular RDF Book Mashup1 now exposes Amazon and eBay offers of new and used copies for more than 100k book titles as GoodRelations data. In an extremely short space of time (approx a year) this ontology has already seen significant commercial use. There is a good possibility that this will revolutionize E-commerce and become the killer application for the semantic web. e killer application for the semantic web.
Grid4AllOntology +The Semantic Information System (SIS) prov The Semantic Information System (SIS) provides a matching and selection service between peers (humans or software agents) that offer or request (place any of the two kinds of orders i.e. either offers or requests) resources and services within grid environments. This service is used by the Grid4All market place. In the market place, resource/service consumers and providers negotiate traded entities in auction based markets, where these markets are spontaneously initiated (instantiated) by different actors, such as resource/services providers, consumers, or 3rd party actors. Markets are accessed as services that are themselves advertised at the Semantic Information System. SIS acts as a registry for the following types of services: Markets, Application Services and Services exposing resources. The SIS may be queried by software agents as well as by human users to select advertised services and resources: Matchmaking happens through different criteria concerning resources and other application specific traded domain entities, as well as services' profiles. The returned query results are ranked according to resources/services matching characteristics and providers'/consumers' features. The matchmaking process is executed in the following cases: A user makes a request, in which case provider-initiated markets offering services/resources are returned A user makes an offer, in which case consumer-initiated markets are returned. After the matchmaking is completed, and a set of results is obtained, there is an additional step prior to their presentation: the ranking process. Matchmaking performs a coarse-grained distinction of results, according to the type of match ("exact" and "subsumes" match). The ranking process provides an ordering of results which reflects the preferences of the user (e.g. preference on specific peers). It should be noted that the ranking process is implemented as a component of SIS, i.e. the Selection component. Finally, the list of results is returned to the user. According to what specifications have been given as input to the system, a list of resources/services may be returned or the list of the corresponding markets. or the list of the corresponding markets.

I

Info Service Ontology +The Info Service Ontology consists of a ba The Info Service Ontology consists of a basic is:InfoService concept (which could maybe related to prv:DataProvidingService, bibo:Collection, sioc:Space or void:Dataset instances) and some additional ones for describing such an information service (currently: is:InfoServiceQuality, is:InfoServiceType and is:InfoServiceContributorType – the specific individuals are currently only proof-of-concept examples). The main hook re. specific websites from an information service is is:info_service, which associates an is:InfoService instance to e.g. a owl:Thing (or e.g. sub class of owl:Thing, e.g. foaf:Document) instance (e.g. a website link). Furthermore, I defined some is:InfoService individuals, especially isi:musicbrainz (see the graphic above and code below) as proof-of-concept example. Therefore, I used also some category definitions from DBpedia (important is also the property is:main_subject for associating a main subject of an Information Service). a main subject of an Information Service).

M

Media Value Chain Ontology +ISO/IEC 21000-19:2010, MPEG Media Value Ch ISO/IEC 21000-19:2010, MPEG Media Value Chain Ontology (MVCO) is an ontology formalizing the media value chain within the framework of ISO/IEC 21000. ISO/IEC 21000-19:2010 understands a media value chain as the process by which a work is conceived, represented, performed, fixated, distributed, or broadcast, and lastly consumed; acknowledging that different chains exist for different works, going through different transformations, being distributed through different channels and being consumed in different manners. The MVCO captures a base model for those different value chains, focusing on the processes relevant to intellectual property. The ontology represents a minimum necessary model common to most markets and jurisdictions reflected in for example, World International Intellectual Property Organization treaties and in regards to any minor differences between different legislations the MVCO is neutral. ISO/IEC 21000-19:2010 declares a normative OWL 1.0 ontology RDF/XML syntax to be used by MVCO enabled applications. MVCO enabled applications can derive software modules within the ISO/IEC 21000 framework based on this common model, handling ontology classes and instances, answering advanced queries and making use of the semantic power of the OWL language. MVCO enabled applications can import the MVCO ontology in extended ontologies adapted to the particular needs of the standard user while granting the logical consistency with the core model and facilitating the operation with third party applications. ISO/IEC 21000-19:2010 includes the definition of an API to facilitate the implementation of MVCO enabled applications, and provides examples of use in practical scenarios. es examples of use in practical scenarios.
Music Ontology +The following material is taken from: http The following material is taken from: http://moustaki.org/phd/ Information management is an important part of music technologies today, covering the man- agement of public and personal collections, the construction of large editorial databases and the storage of music analysis results. The information management solutions that have emerged for these use-cases are still isolated from each other. The information one of these solutions manages does not benefit from the information another holds. In this thesis, we develop a distributed music information system that aims at gathering music- related information held by multiple databases or applications. To this end, we use Semantic Web technologies to create a unified information environment. Web identifiers correspond to any items in the music domain: performance, artist, musical work, etc. These web identifiers have structured representations permitting sophisticated reuse by applications, and these representations can quote other web identifiers leading to more information. We develop a formal ontology for the music domain. This ontology allows us to publish and interlink a wide range of structured music-related data on the Web. We develop an ontology evaluation methodology and use it to evaluate our music ontology. We develop a knowledge representation framework for combining structured web data and analysis tools to derive more information. We apply these different technologies to publish a large amount of pre-existing music-related datasets on the Web. We develop an algorithm to automatically relate such datasets among each other. We create automated music-related Semantic Web agents, able to aggregate musical resources, structured web data and music processing tools to derive and publish new information. Finally, we describe three of our applications using this distributed information environment. These applications deal with personal collection management, enhanced access to large audio streams available on the Web and music recommendation. lable on the Web and music recommendation.

O

OntoClean Meta-Property Ontology +The axiomitization of OntoClean in S5 moda The axiomitization of OntoClean in S5 modal logic entails certain constraints between classes in a taxonomy. These constraints are well within the expressive power of OWL, given the ability to view the *classes* as an "abox" and declare their metaproperties using the rdf:type relation. One very simple way to accomplish this, is to take the OWL version of an ontology, and in a text editor replace owl:class with "http://www.ontoclean.org/ontoclean-dl-v1.owl#Class", and import this ontology. Then add the rdf:type relations to indicate which classes are rigid, dependent, etc. Any OWL reasoner will be able to find inconsistencies in the taxonomy as a result. consistencies in the taxonomy as a result.
Ordered List Ontology +There is a need to describe typed ordered There is a need to describe typed ordered lists or sequences of information resources. The existing approach in the RDF vocabulary, rdf:Seq, has some drawbacks regarding defining explicitly a range for items of a sequence and to query them efficiently with SPARQL, because every slot of a sequence is related by a separate property of the form rdf:_N, where N is a positive integer number, e.g. rdf:_1 (cf. RDF Vocabulary Description Language 1.0: RDF Schema and RDF Semantics ). That’s why, I co-designed the Ordered List Ontology according to a proposal made by Samer A. Abdallah. This ontology should overcome the drawbacks of the existing ordered list modelling approach by enabling more semantics to describe sequences of information resources. As one can see in graphic 'olo:OrderedList concept as graph with relations', the Ordered List Ontology consists of two concepts - olo:OrderedList and olo:Slot. That means an ordered list is a composite of all slots, which are part of this ordered list (related by the property olo:slot). Although, the Ordered List Ontology is OWL based, the ontology also provides "backward" compatibility to the RDFS world. The initial and primary access method to single slots in an ordered list should be olo:index, because this property represents the fixed index of a slot in an ordered list. Thereby, the property olo:length relates to the length of an ordered list, the number of included slots. The secondary access method is its (currently) optional iterator olo:next as shortcut to the next slot in the list. The items, which are arranged in an ordered list, are associated by the property olo:item to a slot. On the basis of the ordered list concept defined in the Ordered List Ontology one can define more specific ordered list definitions, e.g. for media playlist (see the Play Back Ontology) or ranked recommendations (see the Recommendation Ontology). dations (see the Recommendation Ontology).

P

Play Back Ontology +The Play Back Ontology provides basic conc The Play Back Ontology provides basic concepts and properties for describing concepts that are related to the play back domain, e.g. a playlist, play back and skip counter, on/ for the Semantic Web. The play back domain could be seen as a subset of the media domain - it deals with playing back some media, e.g. videos, music tracks or slideshows, somehow. On the basis of this definition the objects that are included into this domain are media objects. That means all concepts of the Play Back Ontology are somehow related to at least one media object. The range of these media objects is currently restricted to the concepts bibo:Document and frbr:Endeavour, incl. all their sub classes, e.g. mo:Track. The pbo:Playlist concept is a sub class of olo:OrderedList and hence, a specialized ordered list of the media domain. Therefore, a pbo:Playlist instance consists of pbo:PlaylistSlot instances (related by pbo:playlist_slot), which are related to at least one media item by using the property pbo:playlist_item. pbo:Playlist has a further sub class, pbo:FixedPlaylist, to described playlists or sections of playlists, which have a strict order, e.g. a section of music tracks that should be played always one after another, or that are somehow related to each other. Furthermore, pbo:Playlist instances can be related to something by using the property pbo:playlist. The Play Back Ontology consists further more of a couple of media action counters, which are represented by pbo:MediaActionCounter. Sub classes of this concept are pbo:PlayBackCounter and pbo:SkipCounter. Due to the property pbo:media_object, which is a sub property of co:object, it is possible to only associate media objects to pbo:MediaActionCounter instances. The Play Back Ontology and the illustrated examples above demonstrates the reutilization, specialization and application of concepts of existing ontologies (Ordered List Ontology, Counter Ontology, Association Ontology, Music Ontology, Similarity Ontology, DCMI Metadata Terms, ...). Please feel free to create further, more specialized concepts and properties, which are based on the introduced ontologies, e.g. describing transition of music tracks in dj mixes (as discussed here). ic tracks in dj mixes (as discussed here).
Process Specification Language (PSL) +For many years, the [http://www.nist.gov/m For many years, the [http://www.nist.gov/msid/ Manufacturing Systems Integration Division] (MSID) has been involved in the definition of a neutral representation of product data, most recently realized through the STEP standard. With that effort well underway, another candidate area for a division focus is the representation of manufacturing process. Like product data, process data is also used throughout the life cycle of a product, from early indications of manufacturing process flagged during design, through process planning, validation, production scheduling and control. In addition, the notion of process also underlies the entire manufacturing cycle, coordinating the workflow within engineering and shop floor manufacturing. The Process Specification Language (PSL) defines a neutral representation for manufacturing processes that supports automated reasoning. Process data is used throughout the life cycle of a product, from early indications of manufacturing process flagged during design, through process planning, validation, production scheduling and control. In addition, the notion of process also underlies the entire manufacturing cycle, coordinating the workflow within engineering and shop floor manufacturing. If you would like to learn more about PSL, including rationale and the need for its implementation, please [http://www.mel.nist.gov/psl/rationale.html click here]. === PSL Ontology -- Current Theories and Extensions (version 2.8) === The axioms of PSL are organized into PSL-Core and a set of extensions. PSL-Core is the set of axioms written in CLIF (the [http://www.nist.gov/cgi-bin/exit_nist.cgi?url=http://philebus.tamu.edu/cl/ Common Logic] Interchange Format) and using only the nonlogical lexicon of PSL-Core. The extensions form a lattice of extensions to PSL-Core. The purpose of PSL-Core is to axiomatise a set of intuitive semantic primitives that is adequate for describing the fundamental concepts of manufacturing processes. Consequently, this characterization of basic processes makes few assumptions about their nature beyond what is needed for describing those processes, and the Core is therefore rather weak in terms of logical expressiveness. In particular, PSL-Core is not strong enough to provide definitions of the many auxiliary notions that become necessary to describe all intuitions about manufacturing processes. To supplement the concepts of PSL-Core, the ontology includes a set of extensions that introduce new terminology. An PSL extension provides the logical expressiveness to express information involving concepts that are not explicitly specified in PSL-Core. For each symbol in the nonlogical lexicon of an extension of PSL, there exist one or more axioms, written in CLIF, that constrain its interpretation. A distinction is drawn between definitional and nondefinitional extensions of PSL-Core. A definitional extension is an extension whose nonlogical lexicon can be completely defined in terms of PSL-Core. Definitional extensions add no new expressive power to PSL-Core. Nondefinitional extensions (also called core theories) are extensions of PSL-Core that involve at least one new primitive not contained in PSL-Core. All extensions within PSL must be consistent extensions of PSL-Core, and may be consistent extensions of other PSL extensions. However, not all extensions within PSL need be mutually consistent. The organization of the extensions below reflects the Parts within standard [http://www.nist.gov/cgi-bin/exit_nist.cgi?url=http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35185&ICS1=25&ICS2=40&ICS3=40 ISO 18629]. All files are updates to the standard, except for those marked by “x”, which are in progress. Other status indicators are: “c” (consistency proof completed) and “ca” (consistency verified by the automated theorem prover [http://www.nist.gov/cgi-bin/exit_nist.cgi?url=http://en.wikipedia.org/wiki/Vampire_theorem_prover Vampire]). The syntax of all files has been checked by automated theorem provers, see [http://www.mel.nist.gov/psl/download.html download page]. The purpose of PSL-Core is to axiomatize a set of intuitive semantic primitives that is adequate for describing the fundamental concepts of manufacturing processes. Consequently, this characterization of basic processes makes few assumptions about their nature beyond what is needed for describing those processes, and the Core is therefore rather weak in terms of logical expressiveness. The basic ontological commitments of PSL-Core are based on the following intuitions: '''Intuition 1:''' ''There are four kinds of entities required for reasoning about processes -- activities, activity occurrences, timepoints, and objects. '' '''Intuition 2:''' ''Activities may have multiple occurrences, or there may exist activities that do not occur at all. '' '''Intuition 3:''' ''Timepoints are linearly ordered, forwards into the future, and backwards into the past. '' '''Intuition 4:''' ''Activity occurrences and objects are associated with unique timepoints that mark the begin and end of the occurrence or object. '' === Key Publications === Bock, C. and Gruninger, M. (2004) [http://stl.mie.utoronto.ca/publications/semantic_domain.pdf PSL: A semantic domain for flow models], '''Software and Systems Modeling'''. Gruninger, M. and Menzel, C. (2003)[http://stl.mie.utoronto.ca/publications/psl-aimag.pdf Process Specification Language: Principles and Applications], '''AI Magazine''', 24:63-74. Cheng, J., Gruninger, M., Sriram, R., and Law, K. (2003)[http://stl.mie.utoronto.ca/publications/pslschedules.pdf Process Specification Language for project scheduling information exchange], '''International Journal of IT in Architecture, Engineering and Construction''', 1:307-328. ngineering and Construction''', 1:307-328.
Property Reification Vocabulary +It seems that there is still a lack in mod It seems that there is still a lack in modelling contextual information for Semantic Graph triples and deploying this knowledge representation reusable in a distributed Linked Data environment. Although, there exists probably applicable solutions for representing external context*, e.g. Named Graphs or N-Quads. However, these methods are not really appropriated to represent internal context* by keeping clear semantics regarding their described Semantic Graph triples (information resource). Even the existing method for RDF statements, RDF Reification (statement reification), has no clear semantics between the statement triple(s) and their reification information resource(s). Furthermore, this method is intended to be applied at the instance level. Although, it might be good to be able to apply reification definition also on the vocabulary level. That means, to reify the semantic relation that is established by a property. This kind of reification is then called property reification. Therefore, the simple semantic relation, represented by subject, predicate and object, is now defined as shortcut relation. Thereby, the predicate is always the same property for a single shortcut relation definition. Beyond, the class that enables a detailed description of such a n-ary relation is called reification class. Due to the reason, that there wasn’t a published vocabulary that addresses a mapping and its semantics between shortcut relations and reification classes and vice versa, Bob Ferris co-designed the Property Reification Vocabulary. This vocabulary is designed after a proposal made by Jiří Procházka, Richard Cyganiak and Toby Inkster and was also extended by Bob Ferris to enable further functionality. It should reflect the important use case and ontology design pattern of property reification. This gives ontology designers the freedom to separate such property reification definitions from their core ontology definition and enable hence the opportunity to make them optional. nce the opportunity to make them optional.

Q

QUDT: Quantities, Units, Dimensions and Types +The QUDT ontologies provide the following: The QUDT ontologies provide the following: # Multiple Systems of Units # Comprehensive Coverage of Quantities # Ontology Support for Units Conversion using Dimensions # Simple and Structured Data Types === Quantities, Quantity Kinds, and Quantity Values === A '''Quantity''' is an observable property of an object, event or system that can be measured and quantified numerically. Quantities are differentiated by two attributes which together comprise the essential parameters needed to formalize the structure of quantities: kind and magnitude. The kind attribute of a quantity identifies the observable property quantified, e.g. length, force, frequency; the magnitude of the quantity expresses its relative size compared to other quantities of the same kind. For example, the speed of light in a vacuum and the escape velocity of the Earth are both quantities of the kind speed but are of different magnitudes. The speed of light in a vacuum is greater than the escape velocity of the Earth. More generally, the speed of light in a vacuum is comparable to the escape velocity of the Earth. Thus, if two quantities of the same kind, their magnitudes can be compared and ordered. However, the same is not true if the quantities are of different kinds. There is no intrinsic way to compare the magnitude of a quantity of mass with the magnitude of a quantity of length. Quantities may arise from definition or convention, or they may be the result of one or a series of experiments and measurements. In the first case, the quantity is ''exact''; in the second case, measurement uncertainty cannot be discounted so the expression of a quantity's magnitude must account for the parameters of uncertainty. === Quantity Kinds === A '''Quantity Kind''' is any observable property that can be measured and quantified numerically. Familiar examples include physical properties such as length, mass, time, force, energy, power, electric charge, etc. Less familiar examples include currency, interest rate, price to earning ratio, and information capacity. === Unit of Measure === A '''Unit of Measure''' or '''Unit''' is a particular quantity of a given kind that has been chosen as a scale for measuring other quantities of the same kind. For example, the Meter is a quantity of length that has been empirically defined by the BIPM. Any quantity of length can be expressed as a number multiplied by the unit meter. More formally, the value of a quantity Q with respect to a unit (U) is expressed as the scalar multiple of a real number (n) and U: Q = nU === Quantity Value === A quantity value expresses the numerical value of a quantity with respect to a chosen unit of measure. For example, the value of Planck's constant in Joule-Seconds (J s) is approximately 6.62606896E-34, whereas the value in Erg-Seconds (erg s) is approximately 6.62606896E-27. The OWL model for the classes qud:QuantityKind, qud:Quantity, qud:QuantityValue, qud:Unit is shown below. === Systems of Quantities and Units === The art and science of defining, standardizing, and organizing quantity kinds and units is ancient and modern. Today, scientific boards and standards bodies maintain rigorous definitions for quantity kinds and units. The definitions of and relationships between quantity kinds are derived from physical laws and mathematical transformations. Units are defined by experimental observations, by the application of physical laws, as ratios of fundamental physical constants, or by reference. One significant advance in the modern treatment of metrology has been the use of logic and mathematics to organize quantity kinds and units into systems and to analyze the relationships between them. A system of quantity kinds is a set of one or more quantity kinds together with a set of zero or more algebraic equations that define relationships between quantity kinds in the set. In the physical sciences, the equations relating quantity kinds are typically physical laws and definitional relations, and constants of proportionality. Examples include Newton’s First Law of Motion, Coulomb’s Law, and the definition of velocity as the instantaneous change in position. In almost all cases, the system identifies a subset of base quantity kinds. The base set is chosen so that all other quantity kinds of interest can be derived from the base quantity kinds and the algebraic equations. A system of units is a set of units which are chosen as the reference scales for some set of quantity kinds together with the definitions of each unit. Units may be defined by experimental observation or by proportion to another unit not included in the system. If the unit system is explicitly associated with a quantity kind system, then the unit system must define at least one unit for each quantity kind. === Base and Derived Quantity Kinds === Many systems of quantity kinds identify a special subset of the included quantity kinds called the base quantity kinds. Base quantity kinds are typically chosen so that no base quantity kind can be expressed as an algebraic relation of one or more other base quantity kinds using only the constituent equations included in the system. A quantity kind that can be expressed as an algebraic relation of one or more base quantity kind is called a derived quantity kind. Thus, in any quantity kind system, the base set and derived set are disjoint. Similarly, unit systems may distinguish between base units and derived units. A base unit is a unit of measurement for a base quantity, and a derived unit is a unit of measurement for a derived quantity. Unit systems define at least one base unit for each base quantity and at least one derived unit for each derived quantity. === Quantity Dimensions === Quantity kind systems that define base and derived sets have certain mathematical properties that permit quantity kinds to be manipulated symbolically. The construction goes as follows: Assign a distinct dimension symbol to each base quantity kind. For each derived quantity kind, take the formula that expresses it in terms of the base quantity kinds and replace every occurrence of a base quantity with its symbol. This is the dimension symbol for the derived quantity kind. In this way, every quantity kind maps to a dimension symbol of the form: dim Q = (B1)d1(B2)d2…(Bn)dn Here {B1,…,Bn} are the dimension symbols for the base quantities and {d1,…,dn} are rational numbers. Typically, the values of the di are between -3 and 3, however magnitudes as high as 7 are required to cover the range of quantity kinds currently defined. Using the multiplication identity for exponents AnAm = An+m one can show that the set of dimension symbols is homomorphic to an n-dimensional vector space over the rational numbers. Multiplication of quantity kinds corresponds to vector addition, division corresponds to vector subtraction, and inverting a quantity kind corresponds to computing the additive inverse of its dimension vector. In some cases, distinct quantity kinds may have the same dimension symbol. This often occurs in cases where physical laws are discovered and formalized independently of each other, but reduce to the same base quantity kinds. Perhaps the most commonly quoted example is the dimensional equivalence of mechanical torque and energy. Both have the same dimensions (L2MT-2) but are defined very differently. One consequence of the equivalence is that the same units of measure are applicable to both. One salient difference between the two in this example is that torque is a pseudo-vector while energy is a scalar. However, this distinction (value type) is not accounted for in the quantity kind system formalism. for in the quantity kind system formalism.

R

Recommendation Ontology +The Recommendation Ontology is an ontology The Recommendation Ontology is an ontology for modeling high level recommendations on/ for the Semantic Web. Thereby, the ontology hook up parts of the Similarity Ontology, DCMI Metadata Terms, the Association Ontology and the Ordered List Ontology. The core of the Recommendation Ontology is the rec:Recommendation concept. A rec:Recommendation instance can consist of * an item or agent relation (rec:Recommendation or its inverse property rec:for) to associate the resource, for which the recommendation was made * an recommender relation (rec:recommender or its inverse property rec:recommends) to associate the instance, which provided or calculated the recommendation, e.g. an is:InfoService instance * recommendation object relations (rec:recommendation_object or its inverse property rec:recommended_in) to associate appropriated objects to the recommendation subject * recommendation audience relations (rec:recommendation_audience to associate groups or stereotypes, which are probably appropriated as target group for this recommendation. Since rec:Recommendation is a sub class of ao:LikeableAssociation, it is also possible to like (ao:likeminded), rate (rev:rating) or give a feedback (rev:Feedback) to a recommendation. Furthermore, one can also relate detailed association (sim:Association) or similarity statements (sim:Similarity) to a recommendation by using the property ao:included_association. As an extension of rec:Recommendation, we built the rec:RankedRecommendation concept to enable also ordered (ranked) recommendations at a high level. rec:RankedRecommendation is not only a sub class of rec:Recommendation. Furthermore, it is also a sub class of olo:OrderedList, which enables all features of an ordered list also to this concept. Following this design, a rec:ranked_recommendation is not only a sub property of rec:recommendation_object, but also a sub property of olo:slot. That means the recommendation objects are now related by using the property olo:item. ow related by using the property olo:item.

S

SKOS +''The following description was borrowed f ''The following description was borrowed from W3C sites describing SKOS.'' Knowledge organization systems play a fundamental role in information structuring and access, e.g. for asset description or web site organization. Such vocabularies, coming in the form of thesauri, classification schemes, subject heading lists, taxonomies or even folksonomies, are developed and used worldwide, by institutions as well as individuals. However these very important knowledge resources are still mostly isolated from the outside world, and not widely used in implementing systems. The development of new information technologies and infrastructures, such as the World Wide Web, calls for new ways to create, manage, publish and use these knowledge organization systems. It is especially expected that conceptual schemes will benefit from greater shareability, e.g. by being published via web services. In the meantime, the documentary systems which use them will turn to advanced information retrieval techniques to construct most of their semantic structure and lexical content. SKOS (Simple Knowledge Organization System) provides a model to represent and use vocabularies and ontologies in the framework of the Semantic Web. A first version (SWBP-SKOS-CORE-GUIDE) has been produced by the Semantic Web Best Practices and Deployment working group, and is already used in some research projects. The Semantic Web Deployment Working Group has been chartered to continue this work, and to "produce guidelines and an RDF vocabulary (SKOS) for transforming an existing vocabulary representation into an RDF/OWL representation". In order to delimit the scope and elicit the required features for SKOS, the SWD working group has issued in December 2006 a call for use cases, asking for descriptions of existing or planned SKOS applications, according to a specific [http://lists.w3.org/Archives/Public/public-swd-wg/2006Dec/0036.html questionnaire]. Following the gathering of these use cases, the Working Group has elicited a number of requirements for SKOS which are motivated by the previous work on SKOS, or by contributions received following the call for use cases. === Use Cases and Requirements Document === The [http://www.w3.org/TR/skos-ucr/ SKOS Use Cases and Requirements] document presents the preparatory work for the 2009 version of SKOS. It lists representative use cases, which were obtained after a dedicated questionnaire was sent to a wide audience. It also features a set of fundamental or secondary requirements derived from these use cases, that have been used to guide the design of SKOS. See the [http://www.w3.org/2006/07/SWD/wiki/UCRMaterial SKOS use cases and requirements page the SWDWG wiki]. All comments are welcome on the following recommendations and may be sent to public-esw-thes@w3.org; please include the text "SKOS comment" in the subject line. All messages received at this address are viewable in a public archive. === Specifications and Documentation === ====SKOS Primer==== [http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/ SKOS Primer]W3C Working Draft 18 August 2009. Antoine Isaac and Ed Summers eds. [http://www.w3.org/News/2009#item140 news release] SKOS—Simple Knowledge Organization System—provides a model for expressing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, folksonomies, and other similar types of controlled vocabulary. As an application of the Resource Description Framework (RDF), SKOS allows concepts to be composed and published on the World Wide Web, linked with data on the Web and integrated into other concept schemes. This document is a user guide for those who would like to represent their concept scheme using SKOS. In basic SKOS, conceptual resources (concepts) are identified with URIs, labelled with strings in one or more natural languages, documented with various types of note, semantically related to each other in informal hierarchies and association networks, and aggregated into concept schemes. In advanced SKOS, conceptual resources can be mapped across concept schemes and grouped into labelled or ordered collections. Relationships between concept labels can be specified. Finally, the SKOS vocabulary itself can be extended to suit the needs of particular communities of practice or combined with other modelling vocabularies. This document is a companion to the [http://www.w3.org/TR/skos-reference SKOS Reference], which gives the normative reference on SKOS. ====Use Cases and Requirements==== [http://www.w3.org/TR/2009/NOTE-skos-ucr-20090818/ SKOS Use Cases and Requirements]W3C Working Draft 18 August 2009. Antoine Isaac, Jon Phipps, Daniel Rubin eds. Knowledge organization systems, such as taxonomies, thesauri or subject heading lists, play a fundamental role in information structuring and access. The Semantic Web Deployment Working Group aims at providing a model for representing such vocabularies on the Semantic Web: SKOS (Simple Knowledge Organization System). This document presents the preparatory work for the 2009 version of SKOS. It lists representative use cases, which were obtained after a dedicated questionnaire was sent to a wide audience. It also features a set of fundamental or secondary requirements derived from these use cases, that have been used to guide the design of SKOS. This document is a companion to the [http://www.w3.org/TR/skos-reference SKOS Reference] and the [http://www.w3.org/TR/skos-primer SKOS Primer], which respectively provide the normative reference on SKOS and a user guide for those who would like to represent their concept scheme using SKOS. See also [http://references/ Tutorials, Presentations & Papers] and [http://translations/ Translations].  and [http://translations/ Translations].
SNomenclature Ontology +The Semantic Nomenclature Application Onto The Semantic Nomenclature Application Ontology is the core of the ontology network used in the scenario. This ontology has three main goals: act as a bridge between the different application ontologies and domain ontologies; the second goal is implement one the new requirements as the disambiguate between the clinical drug/branded drug; the third functionality is act as the application ontology for the Semantic Nomenclature prototype, because from this ontology, using the mappings and relations can be accessed the rest of the ontology network. The Ontology is based on the main recommendations provided by the pharmaceutical product, and also using the semantic model of Snomed as background knowledge, mainly from the Pharmaceutical/Biological product term used in the terminology. ical product term used in the terminology.
(previous 25) (next 25)
Personal tools
Quality Committee
Content OP publishers