Your SlideShare is downloading. ×
0
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Introducing FRSAD and Mapping it with Other Models
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introducing FRSAD and Mapping it with Other Models

1,867

Published on

Report on the work of the IFLA FRSAR (Functional Requirements for Subject Authority Records) Working Group. …

Report on the work of the IFLA FRSAR (Functional Requirements for Subject Authority Records) Working Group.
1. Introducing the FRSAD model.
2. Mapping to other models (BS 8723 and ISO 25964, SKOS, OWL, & DCMI-AM).
(Presented at IFLA2009 Milan, 08, 2009 by Marcia Zeng and Maja Zumer)
Paper and FRSAD report available at:http://nkos.slis.kent.edu/FRSAR/index.html

Published in: Education, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,867
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • • Group 1 entities are defined as the products of intellectual or artistic endeavors: work, expression, manifestation, and item • Group 2 entities are actors, those who are responsible for the intellectual or artistic content, the physical production and dissemination, or the custodianship, of Group 1 entities: person, corporate body • Group 3 entities are the subjects of works, intellectual or artistic endeavor
  • http://www.cas.org/ASSETS/93FD034A0502489FA2474DFC0EE03284/usan.pdf
  • shows a screen captured from the Art and Architecture Thesaurus (AAT) online version. Hierarchical relationships of concepts "mercury " and both "nonferrous metal " (under the node "<metal by composition or origin>") and "elements " (under the node "<materials by chemical form>") are presented in the hierarchies.
  • This is why nomen (in general) has to be an entity, not an attribute of thema. In a particular implementation the relationship between a thema and nomen can be compressed into the nomen becoming an attribute of thema
  • This approach to separate thema from what it is known by, referred to, or addressed (i.e., nomen) can find its root in the classical model and literature reviewed below. Ogden & Richard's (1923) famous triangle of meaning illustrated the relationship between language, thought content, and referent . The graph implies that the referent of an expression (a word or another sign or symbol) is relative to different language users. The theoretical foundation of it can be traced back to Aristotle who distinguished objects, the words that refer to them, and the corresponding experiences in the psyche , as well as Frege who distinguished between two types of meaning: thought content and referent in his essay “On Sinn und Bedeutung” (Campbell et al., 1998). "In Plato's Cratylus , Socrates argues that it is not enough to try to understand what a thing is, based on its name, because the name-givers may have been living in ancient times, and the name reflects only what the name-givers thought was the nature of reality then; however, they may have been wrong. Thus, it has been historically recognized that multiple terms may refer to the same object or idea, a single term may refer ambiguously to more than one object or idea, and terms may be confusing because they are out of date" (Campbell, et al., 1998).
  • A model for structured vocabularies (more specifically, thesauri) was defined by the British standard BS8723-5: Structured vocabularies for information retrieval – Guide. Part 5: Exchange formats and protocols for interoperability (DD 8723-5:2008). (The model, XML Schema, and examples are available at the BS8723 Official Development Website). This model has been slightly revised and included in the ISO/CD 25964-1 Information and documentation — Thesauri and interoperability with other vocabularies — Part 1: Thesauri for information retrieval (2008: 92) which went out for ballot at the beginning of 2009.
  • SKOS 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 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. SKOS Reference W3C Candidate Recommendation 17 March 2009 Latest Version: http://www.w3.org/TR/skos-reference/
  • To present this structure, we can use the graph here: for each concept, the preferred label, alternative label or labels, broader, narrower, and related concepts. There is also a scope note on concept.
  • (Drawn based on SKOS Reference , June 2008, ©Zeng, 2008, ISKO-NA Conference, Montreal. Validated 2009-03) Let me illustrate the SKOS synopsis here. Using SKOS, concepts can be identified using URIs, labeled with lexical strings in one or more natural languages, assigned notations (lexical codes), documented with various types of note, linked to other concepts , and organized into informal hierarchies and association networks (to be continued.)
  • (continued from previous slide) concepts are -- organized into informal hierarchies and association networks, aggregated into concept schemes , grouped into labeled and/or ordered collections , and mapped to concepts in other schemes. The SKOS Synopsis helps us to understand how 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.
  • SKOS model is based on a concept-centric view of vocabulary, where primitive objects are not labels; rather, they are concepts represented by labels. These can be matched to what have been defined in the FRSAD model, in terms of thema , nomen and their attributes. SKOS also has specific properties to represent all the semantic relationships, which matches the ones defined by FRSAD as well.
  • Image credit: http://rarebirdfinds.typepad.com/rare_bird_finds/images/2007/07/30/owl_decal.jpg OWL is the most recently developed standard ontology language, endorsed by the W3C to promote the Semantic Web vision. At least two different user groups OWL used as data exchange language (define interfaces of services and agents) -- OWL used for terminologies or knowledge models Most of us are still in this user group.
  • OWL is an ontology language that is primarily designed to describe and define classes. Classes are therefore the basic building blocks of an OWL ontology. Let us take a look at an enumerated class.
  • DCMI Abstract Model is the formal modeling basis for Dublin Core metadata; It is like a “grammar” for Dublin Core and has a strong link with parallel development of RDF (Resource Description Framework).
  • In summary, the constructs of a record should be the descriptions, and in each description, there are statements. The statements contain either value URI, or literals.
  • In conclusion, the FRSAD model is developed with the goal to assist in an assessment of the potential for international sharing and use of subject authority data both within the library sector and beyond. The FRSAD model and other models developed along with the progress of the Semantic Web during the recent years enable the consideration of the functions of subject authority data and concept schemes at a higher level that is independent of any implementation, system, or specific context, and will allow us to focus on the semantics, structures, and interoperability of subject authority data. Putting the subject authority data in the context of the Semantic Web developments, especially in the perspective of Linked Data, subject authority data that are modeled based on FRSAD and encoded in SKOS and OWL will be able to become part of the Linked Data and contribute to the development of the Semantic Web.
  • Many references are available on the Web. You may find more on the Dublin Core Metadata Initiatives (DCMI) website. In this metadata lecture week, we only discussed why metadata are needed, where they are usually stored or found, how they impact an information system, and what an abstract model is about. We did not go into details of any standards. In the last part, we touched on the abstract model. This mode brings us out of the traditional way of thinking around a record, and leads us to consider metadata statements as the basic unit in describing and communicating about a resource. The model of resources, properties, and values, will be applied to ontology development. It is how ontologies advance and differ from all other kinds of KOS structures.
  • Transcript

    • 1. Introducing FRSAD and Mapping it with Other Models [FRSAD = Functional Requirements for Subject Authority Data] Marcia L. Zeng, Kent State University, USA Maja Žumer, University of Ljubljana, Slovenia Based on the work of the IFLA FRSAR Working Group IFLA 2009, Milan, Italy IFLA 2009, Milan, Italy
    • 2. Acknowledgement This paper is based on the work of the FRSAR (Functional Requirements for Subject Authority Records) Working Group, established by the IFLA Division IV Bibliographic Control and especially the Section of Classification and Indexing. IFLA, OCLC, and Kent State University have provided funding, facilities, and tremendous support. 2
    • 3. Outline 1. Introducing the FRSAD model 2. Mapping to other models (BS 8723 and ISO 25964, SKOS, OWL, DCMI-AM) 3
    • 4. 1. Introducing the FRSAD model FRSAD = Functional Requirements for Subject Authority Data
    • 5. FRBR Functional Requirements for Bibliographic Records (FRBR) Approved by IFLA in 1997 Published in 1998 Conceptual model of the ‘bibliographic universe’ IFLA. (1998). Functional Requirements for Bibliographic Records: Final Report. IFLA Study Group on the Functional Requirements for Bibliographic Records. München: KG Saur. http://www.ifla.org/publications/functional-requirements-for-bibliographic-records 5
    • 6. The “FRBR family” FRBR: the original framework All entities, focusing on Group 1 entities FRAD: Functional Requirements for Authority Data Focusing on Group 2 entities Published recently FRSAD: Functional Requirements for Subject Authority Data Focusing on Group3 entities FRSAR WG established in 2005 Draft Report was available for comment by end of July Several comments received 6
    • 7. FRSAR Working Group FRSAR = Functional Requirements for Subject Authority Records Terms of Reference 1. to build a conceptual model of Group 3 entities within the FRBR framework as they relate to the aboutness of works, 2. to provide a clearly defined, structured frame of reference for relating the data that are recorded in subject authority records to the needs of the users of those records, and 3. to assist in an assessment of the potential for international sharing and use of subject authority data both within the library sector and beyond. 7
    • 8. ‘has as subject’ relationship in FRBR ALL the resources to which a library provides access ALL the agents related to Group 1 Additional things that can be “subject of” work 8
    • 9. FRSAD’s relation to FRBR 9
    • 10. FRSAD Conceptual Model 10
    • 11. FRSAD Part 1: WORK has as subject THEMA / THEMA is subject of WORK. This model confirms one of the basic relationships defined in FRBR: WORK has as subject THEMA / THEMA is subject of WORK • Thema = "any entity that can be subject of a work". • Thema includes any of the FRBR entities:  Group 1 and Group 2 entities and,  in addition, all other subjects of works.  11
    • 12. FRSAD Part 2: THEMA has appellation NOMEN / NOMEN is appellation of THEMA. This model also proposes a new relationship: THEMA has appellation NOMEN / NOMEN is appellation of THEMA • NOMEN = any sign or sequence of signs (alphanumeric characters, symbols, sound, etc.) by which a thema is known, referred to or addressed as. 12
    • 13. Part 2b Note: in a given controlled vocabulary and within a domain, a nomen should be an appellation of only one thema, 13
    • 14. NOMEN = any sign or sequence of signs (alphanumeric characters, symbols, sound, etc.) by which a thema is known, referred to or addressed as. Example: different types of nomen nomen representation=“graphic” Source: STN Database Summary Sheet: USAN (The USP Dictionary of U.S. Adopted Names and International Drug Names) 14
    • 15. Choice of terms (thema, nomen) Different and overlapping meaning of ‘subject’, ‘topic’, ‘concept’, ‘class’, etc. Different views on granularity ‘Name’ understood as ‘proper name’ Therefore: Terms from Latin that do not have to be translated and are not loaded with other meanings 15
    • 16. Attributes Some general attributes of thema and nomen are proposed In an implementation additional attributes may be recorded 16
    • 17. Thema-to-thema relationships Hierarchical Partitive Generic Instance Associative Other thema-to-thema relationships are domain- or implementation-dependent 17
    • 18. Example: An online display record of the AAT concept “Mercury” 18 Source: Art and Architecture Thesaurus Online
    • 19. Nomen-to-nomen relationships Partitive Equivalence Equivalence can be specified further, e.g.: replaces/is replaced by has variant form/is variant form has derivation/is derived from has acronym/is acronym for has abbreviation/is abbreviation of has transliterated form/is transliteration of 19
    • 20. The importance of the THEMA- NOMEN model to the subject authority data to separate what are usually called concepts (or topics, subjects, classes [of concepts]) from what they are known by, referred to, or addressed as A general abstract model, not limited to any particular domain or implementation Potential for interoperability within the library field and beyond 20
    • 21. Future development of FRSAD Comments collected from the 1st world-wide review are to be analysed and discussed New document will be prepared by the end of 2009 2nd review is expected in 2010 Final report is targeted for submission in 2010 21
    • 22. Relationship of FRSAD with FRBR A generalisation of FRBR (no predefined entities in Group3) Introduction of nomen New user function: explore 22
    • 23. Relationship of FRSAD with FRAD Independent parallel development; no hierarchical relationship FRAD was published after FRSAD was available for comments Different user functions ( FRAD justify and contexualise / FRSAR explore) Similar approach (name; nomen), but not identical FRSAD nomen is a superclass of FRAD name, identifier and controlled access point 23
    • 24. The future: harmonisation of the FRBR family A new working group under the umbrella of the FRBR RG will have to develop a new model, taking FRAD and FRSAD into account A new name? 24
    • 25. 2. Mapping to Other Models
    • 26. 2.1 Ogden & Richard's (1923) triangle of meaning the referent of an expression (a word or another sign or symbol) is relative to different language users. multiple terms may refer to the same object or idea, a single term may refer ambiguously to more than one object or idea, terms may be confusing because they are out of date 26
    • 27. 2.2 British standard BS8723-5: Structured vocabularies for information retrieval – Guide. Part 5: Exchange formats and protocols for interoperability (DD 8723- 5:2008). It includes what is needed for modeling: (1) a whole thesaurus, (2) arrays of thesaurus concepts, and (3) records that document a thesaurus entry. In the model, each concept in a structured vocabulary (especially in a thesaurus) is represented by one preferred term per language, and by any number of nonpreferred terms. The notation, scope note and broader/narrower/related term relationships apply to the concept as a whole, rather than to its preferred term. 27
    • 28. BS8723-5 model Thesaurus’ metadata Thesaurus NodeLabel Record (of thema+nomen) +identifier: String[1..*] +contributor: String[0..*] +Notation: String[0..1] +LexicalValue: String[1] +coverage: String[0..*] +created: date[0..1] +creator: String[0..*] +modified: date[0..1] thema-to- +date: date[0..*] +created: date[0..1] +lang: language[0..1] +modified: date[0..*] +IsLabelledBy 0..* thema +description: String[0..*] +format: String[0..*] 1 ThesaurusArray +language: language[1..*] +Labels +publisher: String[0..*] +identifier: String[1] 1 +relation: String[0..*] 0..* +Ordered: Boolean = false[1] +rights: String[0..*] +Thesaurus +C ontains +source: String[0..*] +subject: String[0..*] +title: String[0..*] +HasMember <ordered> +type: String[0..*] 0..* +HasSuperOrdinate +isPartOf 1 0..1 +C ontains 1..* 0..1 +HasSubordinate nomen-to- 0..* ThesaurusConcept +identifier: String[1] +HasSuperOrdinate 0..* TopLevelRelationship +HasTopC oncept +created: date[0..1] nomen 0..* +modified: date[0..1] +Status: String[0..1] 1..* +HasMember <ordered> +IsMemberOf 0..* +IsTopC onceptOf +Notation: String[0..*] 0..* +TopC oncept: Boolean[0..1] HierarchicalRelationship +HasHierRelC oncept 0..* +Role: String[1] 0..* AssociativeRelationship +HasRelatedC oncept +IsHierRelC oncept +Role: String[0..1] 0..* CustomAttribute +IsRelatedC oncept 1 +HasAttribute +LexicalValue: String[1] 1 +IsAttributeOf 0..* +C ustomAttributeType: String[1] +Labels 1 0..* +IsReferredToIn Note +Labels 1 1 +RefersTo 0..* +LexicalValue: String[1] Equivalence CompoundEquivalence +created: date[0..1] +Annotates +DefinesScopeOf +modified: date[0..1] +Role: String[0..1] +lang: language[0..1] ScopeNote 0..* 0..* +HasNonPreferredTerm +HasPreferredTerm 1..* 2..* 0..* +HasScopeNote SimpleNonPreferredTerm PreferredTerm CompoundNonPreferredTerm +UF +USE +USE+ +UF+ 0..* 0..* 1 HistoryNote +HasHistoryNote ThesaurusTerm 1 0..* +LexicalValue: String[1] +Annotates +HasHistoryNote +identifier: String[1] +created: date[0..1] Definition 1 0..* +modified: date[0..1] +source: String[0..1] +source: String[0..1] +IsDefinitionOf +HasDefinition +Status: String[0..1] +lang: language[0..1] 1 0..* EditorialNote +Annotates +HasEditorialNote 28
    • 29. FRSAD and BS8723-5/ ISO 25964 Model BS8723-5 model is adopted by ISO 25964 Thesauri and interoperability with other vocabularies, with some revisions Both represent these relationships: (1) thema-and-nomen (a record documenting a concept and its nomen(s), (2) thema-and-thema (hierarchical (broader, narrower, and top concepts)) and associative (related concepts), and (3) nomen-and-nomen (preferred and non-preferred, variant lexical forms, and in various languages). 29
    • 30. 2.3 SKOS (Simple Knowledge Organization System) -- provides a model for expressing the basic structure and content of concept schemes such as Thesauri Classification Schemes Taxonomies Subject Heading lists Folksonomies, and other similar types of controlled vocabulary. -- is an application of RDF -- allows concepts to be composed published on the Web linked with data on the Web and integrated into other concept schemes. 30 --SKOS Reference, http://www.w3.org/TR/skos-reference/
    • 31. SKOS for a thesaurus entry Concept URI [concept] Preferred label labels Alternative label Concept URI Broader concept Concept URI term@en label term@fr term@en label s entry-terms s term@fr notation@scheme1 entry-terms notation@schemen notation@scheme1 alternative-notations notation@schemen notes alternative-notations notes Concept URI Narrower concept Concept URI term@en label term@fr term@en label s entry-terms s term@fr notation@scheme1 entry-terms notation@schemen notation@scheme1 alternative-notations notation@schemen notes alternative-notations notes Concept URI Concept URI label Related concept term@en term@fr term@en label s entry-terms s term@fr notation@scheme1 entry-terms Scope note on concept notation@schemen notation@scheme1 alternative-notations notation@schemen notes alternative-notations notes notes © zeng, 2008-2009 31
    • 32. SKOS Synopsis (1) Concept URI Concept URI term@en label term@fr term@en label s entry-terms s term@fr notation@scheme1 entry-terms Using SKOS, notation@schemen notation@scheme1 alternative-notations notation@schemen notes alternative-notations Concept URI notes concepts can be identified using URIs labels term@en term@fr labeled with lexical strings in one entry-terms or more natural languages, assigned notations (lexical notation@scheme-1 codes) notation@scheme-n alternative-notations documented with various types notes of note Concept URI Concept URI label term@en term@fr term@en label s entry-terms s term@fr linked to other concepts notation@scheme1 entry-terms notation@schemen notation@scheme1 alternative-notations notation@schemen Concept URI notes alternative-notations Concept URI notes label and term@en term@fr term@en label s entry-terms s term@fr notation@scheme1 entry-terms notation@schemen notation@scheme1 alternative-notations notation@schemen organized into notes alternative-notations notes informal hierarchies and association networks (to be continued ) 32 © zeng, 2008-2009
    • 33. SKOS Synopsis (2) (continued from previous slide, -- concepts are organized into informal hierarchies and association networks) •aggregated into concept schemes, • [grouped into labeled and/or ordered collections, ] • and mapped to concepts in other schemes. 33 © zeng, 2008-2009
    • 34. SKOS and FRSAD models SKOS model is based on a concept-centric view of vocabulary, where primitive objects are not labels; rather, they are concepts represented by labels. These can be matched to what have been defined in the FRSAD model, in terms of thema, nomen and their attributes. SKOS also has specific properties to represent all the semantic relationships, which matches the ones defined by FRSAD as well. 34
    • 35. 2.4 OWL Web Ontology Language standard ontology languages endorsed by the W3C to promote the Semantic Web vision. At least two different user groups: OWL used as data exchange language (define interfaces of services and agents) OWL used for terminologies or knowledge models 35
    • 36. OWL Classes OWL is an ontology language that is primarily designed to describe and define classes. Classes are therefore the basic building blocks of an OWL ontology. OWL provides axioms (statements that say what is true in the domain) that allow relationships to be established between class expressions, including: SubClassOf, EquivalentClasses, DisjointClasses, and DisjointUnion. 36
    • 37. In OWL, classes and property expressions are used to construct ‘class expressions’, (sometimes also called ‘descriptions’, and, in the description logic literature, ‘complex concepts’). ObjectIntersectionOf, ObjectUnionOf, and ObjectComplementOf ObjectOneOf -- contains exactly the specified individuals 37
    • 38. OWL and FRSAD For the issues of the complexity and granularity of themas and comprehensive semantic relationships between and among themas that FRSAD attempted to cover, OWL has great matches. 38
    • 39. Described resource Described resource Property = type of relationship Property = type of relationship Value = other resource Value = other resource 2.5 DCMI Abstract Model Formal modeling basis for Dublin Core metadata Like a “grammar” for Dublin Core Strong link with parallel development of RDF (Resource Description Framework) 39
    • 40. The constructs of a record 记录 records 描述 descriptions 陈述 statements Source: Nilsson, 2007: slide 12 40
    • 41. DCMI-AM and FRSAD The FRSAD model corresponds to the DCMI Abstract Model by allowing any thema to be independent of any nomen, including any syntax that a nomen may use. Thus this conceptual model will facilitate the sharing and reuse of subject authority data amongst not only the subject vocabularies themselves, but also metadata resources. 41
    • 42. Conclusion The FRSAD model is developed with the goal to assist in an assessment of the potential for international sharing and use of subject authority data both within the library sector and beyond. The FRSAD model will: enable the consideration of the functions of subject authority data and concept schemes at a higher level that is independent of any implementation, system, or specific context, and allow us to focus on the semantics, structures, and interoperability of subject authority data. 42
    • 43. Draft Report available at: FRSAR: Functional Requirements for Subject Authority Data (FRSAD) http://nkos.slis.kent.edu/FRSAR/ Working Group: Leda Bultrini, Lois Mai Chan, Jonathan Furner, Edward O’Neill, Gerhard Riesthuis, Athena Salaba, Diane Vizine-Goetz, Ekaterina Zaytseva, Marcia Lei Zeng, and Maja Zumer. Advisory Group: Victoria Francu, Hemalata Iyer, Dorothy McGarry, David Miller, Päivi Pekkarinen, and Barbara Tillett. 43
    • 44. References Baker, Thomas. 2005. "Diverse vocabularies in a common model: Dublin Core at 10 years." Presentation at DC-2005: Vocabularies in Practice. Available at http://dc2005.uc3m.es/program/presentations/2005-09-12.plenary.baker-keynote.ppt Nilsson, Mikael. 2007. DCMI Basic Syntaxes Tutorial. DC-2007: International Conference on Dublin Core and Metadata Applications: Application Profiles and their Application in Practice. 27-31 August 2007, Singapore. Available at http://www.dc2007.sg/T2-BasicSyntaxes.pdf Dublin Core Metadata Initiatives (DCMI) http://dublincore.org/ OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax. (2009). Motik, B, Patel-Schneider, P.F. and Parsia, B. eds. W3C Working Draft 21 April 2009. http://www.w3.org/TR/owl2-syntax/ BS8723 Official Development Website. (2008). http://schemas.bs8723.org/Home.aspx SKOS Simple Knowledge Organization System Reference. (2009). W3C Candidate Recommendation 17 March 2009; http://www.w3.org/TR/2009/CR-skos-reference- 20090317/ SKOS Reference (2009). W3C Candidate Recommendation 17 March 2009. Available at: Miles, Alistair. (2008). The Web and SKOS, ISKO London, July 2008. Available at: www.iskouk.org/presentations/miles_web_and_skos_200807.pdf Miles, Alistair. (2005) SKOS Core Tutorial, DC-2005, Madrid. Available at: http://www.dublincore.org/resources/training/dc-2005/tutorial4_eng.pdf 44

    ×