Re: Unicode Characters to display SKOS relations

Thanks Simon.
Yes, Venn diagrams are fine and yes, they are used in a number of BSI 
and ISO standards.

But for the moment I'm asking only about a limited number of 
relationship/mapping types and how to represent them with tags and or 
symbols. (I'm not even going as far as icons, though I'm very happy for 
you and Christophe and others to do so.) The feedback I am keen to 
receive is about the proposed use of the tags/symbols:
   EQ              equivalence mappings (between concepts)
   BM              broader mapping  (or broader match)
   NM              narrower mapping (or narrower match)
   RM              related mapping (or related match)
   ~    inexact

Comments welcome
Stella
*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
stella@lukehouse.org
*****************************************************

Simon Spero wrote:
> Stella/Cristophe-
> 
>   It looks like Cristophe's iconography seems to be converging on 
> something resembling  Venn/Euler diagrams. This is an excellent idea, as 
> a lot of the subtleties related to mapping concepts become intuitively 
> obvious when drawn this way.  Venn diagrams are part of mass culture now 
> (Izzard 2003b <http://www.youtube.com/watch?v=CBpWwC9qNpA>).
> 
> There are some examples of illustrating  relations using venn diagrams 
> in Soergel (1974), Cruse (1986), and Croft and Cruse (2004);  I think 
> the BSI standards use them as well (Stella? Stella!)
> 
> There were probably symbols for this kind of thing in Blissymbolics.  If 
> there were, I suggest they be left to rest in pieces).
> 
> The tricky part would seem to be making the directionality clear, and 
> roughly indicating the additional semantics of the mapping relationships 
> compared to the regular ones (for example,  the broadmatch is the unique 
> smallest concept in the second concept scheme which contains the entire 
> concept from the first scheme.
> 
> It's also tricky making icons that are intelligible at the target image 
> size.
> 
> 
> Simon
> 
> Izzard, Eddie and A. Pappas (Director) (2003a ). Circle. DVD. WEA Corp. 
> ASIN: B0000ALA3P. Sept. 2003.
> — (2003b ). “Venn and His Diagrams”. In: Circle. Youtube clip. URL: 
> http://www.youtube.com/watch?v=CBpWwC9qNpA
> 
> Croft, William and D. Alan Cruse (2004). /Cognitive linguistics/. 
> Cambridge University Press.
> Cruse, D. Alan. (1986). Lexical semantics/. Cambridge University Press.
> Soergel, Dagobert (1974). Indexing languages and thesauri: construction 
> and maintenance. Information sciences series. Los Angeles: Melville Pub. 
> Co. ISBN: 0471810479.
> 
> 
> 2010/2/8 Stella Dextre Clarke <stella@lukehouse.org 
> <mailto:stella@lukehouse.org>>
> 
>     Christophe's ideas for icons look very promising. You may be
>     interested to compare with ideas-in-progress in ISO NP 25964.
> 
>     We are currently debating and drafting ISO 25964 Part 2, which deals
>     with mapping between thesauri, and between thesauri and other sorts
>     of vocabulary. We are hoping to provide for mapping types which
>     align reasonably well with those in SKOS (although we hope also to
>     provide for one-to-many mappings, not yet represented in SKOS).
> 
>     We come from the long-standing tradition of representing
>     relationships within one thesaurus with the following tags:
> 
>     USE/UF          equivalence between terms
>     BT              broader term (really broader concept)
>     NT              narrower term (really narrower concept)
>     RT              related term (really related concept)
> 
>     If you can imagine a mixed display to include these relationships
>     alongside mappings between thesauri, it seems useful to distinguish
>     them in some may, so that internal relationships are not confused
>     with external mappings. Therefore we are considering:
> 
>     EQ              equivalence mappings (between concepts)
>     BM              broader mapping  (or broader match)
>     NM              narrower mapping (or narrower match)
>     RM              related mapping (or related match)
> 
>     So far, so simple; but what about inexact equivalence? We are now
>     considering introduction of the tilde (~) to indicate inexactitude.
>     Thus "EQ~" or "~EQ" would show an inexact equivalence mapping. The
>     definition of this type of mapping is not far from the SKOS notion
>     of closeMatch. And there is a reasonable analogy in Maths for this
>     symbol.
> 
>     I'm mentioning this in response to Christophe's proposals (which in
>     general seem a good idea), because our tilde would not align well
>     with the way he proposes to use rather similar (but more elaborate)
>     symbols, and that could slightly upset our hopes for alignment with
>     SKOS. I don't think we'll venture into the amazing range of icons he
>     has proposed, but it would be nice to avoid clashes.
> 
>     I should stress that our ideas for tags/symbols, and indeed for the
>     mappings themselves, are by no means final. This is a good stage for
>     comments from anyone on any aspect of the above proposals, because
>     we still have room for manoeuvre. That said, I'd like to keep the
>     tilde if we can - short, sweet and simple, and it's on our keyboards.
> 
>     Any comment?
>     Stella Dextre Clarke,
>     Project Leader, ISO NP 25964
>     *****************************************************
>     Stella Dextre Clarke
>     Information Consultant
>     Luke House, West Hendred, Wantage, OX12 8RR, UK
>     Tel: 01235-833-298
>     Fax: 01235-863-298
>     stella@lukehouse.org <mailto:stella@lukehouse.org>
>     *****************************************************
> 
> 
> 
> 
> 
> 
>     Christophe Dupriez wrote:
> 
>         Dear Simon,
> 
>         You are right: my goal is to make big displays of thesauri
>         legible, not to invent new mathematics.
>         Using well known mathematical symbols are problematic. Unicode
>         implies reuse of existing symbols, already loaded with some
>         meanings.
> 
>         So I updated my proposal again to take your remark. Please
>         (re)look at:
>         http://www.destin.be/ASKOSI/Wiki.jsp?page=Icons%20for%20SKOS
> 
>         I did not finalize icons for "matching" relations but I will
>         following the next wave of comments.
> 
>         New icons:
>         Concept:
>         ConceptScheme:
>         Broader:
>         Narrower:
>         Related:
> 
>         Example:
>         http://www.destin.be/ASKOSI/Wiki.jsp?page=Icons%20for%20SKOS#section-Icons+for+SKOS-WithIcons
> 
>         Thanks for the references (especially Dagobert Soergel which
>         works like me for Digital Libraries).
> 
>         Have a nice w.e.
> 
>         Christophe
> 
>         Simon Spero a écrit :
> 
>             ----
>             Useful sources:
> 
>             Croft, William and D. Alan Cruse (2004). /Cognitive
>             linguistics/. Cambridge University Press.
> 
>             Cruse, D. Alan. (1986). /Lexical semantics/. Cambridge
>             University Press.
> 
>             Riesthuis, Gerhard J. A. et al. (2008). /Guidelines for
>             Multilingual Thesauri/. IFLA Professional Reports,
>             No. 115. The Hague, NL: International Federation of Library
>             Associations and Institutions. URL:
>             http://www.ifla.org/VII/s29/pubs/Profrep115.pdf
> 
>             Soergel, Dagobert (1974). Indexing languages and thesauri:
>             construction and maintenance. Information sciences series.
>             Los Angeles: Melville Pub. Co. ISBN: 0471810479.
> 
>             In fact, read as much Soergel as you can find :-)
> 
>             ----------
> 
>             I'm not sure if the semantics of SKOS are quite right for
>             the mathematical symbols  you're using
> 
>             Let the type Δ denote the domain of discourse to which
>             labels might be attached.
>             Let the type Σ denote the set of all possible label strings .
>             Let the type CONCEPT denote a two-tuple, (Σ × ℙ(Δ))  
>             containing a label and a set of elements of Δ .
>             Let the type CONCEPT-SCHEME denote a  2-tuple (Σ  ×
>              ℙ(CONCEPT)).
> 
>             Let c and k denote two arbitrary CONCEPTs
>             Let C and K denote two arbitrary CONCEPT-SCHEMEs
> 
>             Let label(k) refer to the first element of CONCEPT k.
>             Let documents(k) refer to the second element of CONCEPT k.
>             Let label(C) refer to the first element of a CONCEPT-SCHEME C.
>             Let concepts(C) refer to the second element of a
>             CONCEPT-SCHEME C.
> 
>             Let the 2-tuple (c,C) denote a fully qualified concept (FQC)
>             consisting of  of a concept and a concept scheme,  where c ∈
>             concepts(C).
> 
>             BT, NT, and EQ for a single CONCEPT scheme.
> 
>             Within a single CONCEPT-SCHEME C, such that c ∈ C ⋀ k ∈ C
> 
>             1: ( BT)    c < k    iff documents(c) ⊂ documents(k)
>             2: (NT)    c > k     iff documents(c) ⊃ documents(k)
>             3: (SY)    c  ≍ k    iff documents(c) ≡ documents(k)
> 
>             Unique Concept Scheme Name Assumption
>             4: ∀ C ∈ CONCEPT-SCHEME. ∀ K ∈ CONCEPT-SCHEME. label(C) ≡
>             label(D)  → C ≡ D
> 
>             Within Scheme Unique Preferred Name Assumption
>             5: ∀ C ∈ CONCEPT-SCHEME. ∀ c ∈ concepts(C).  ∀ d ∈
>             concepts(C).  label(c) = label(d) → c ≡ d
> 
>             Identity
>             6: C = K    iff   label(c) ≡ label(k) ⋀  concepts(c) ≡
>             concepts(k)
>             7: c = k     iff   label(c) ≡ label(k) ⋀  documents(c) ≡
>             documents(k) ^ ∀ C ∈ CONCEPT-SCHEME. c ∈ concepts(C) iff k ∈
>             concepts(C)
> 
> 
>             Mapping Relations
>               Note that mapping relations are only defined between
>             concepts in different concept schemes.
> 
>             Exact match, (c,C) ≍ (k,K)
>             8: For an exact match, (c,C) ≍ (k,K)
>                (c,C) ≍ (k,K) iff C ≢ K ⋀  documents(c) ≡ documents(k)
> 
>             Broad Match:  (c,C)  ⪷ (k,K)
> 
>             9: (c,C) ⪷ (k,K)  iff
>                          ¬ (c,C) ≍ (k,K) ⋀
>                           c < k  ⋀
>                          ∄d ∈ concepts(K). (c < d ⋀ d < k  ⋀ d ≠ k)
> 
>             Narrower Match: (c,C) ⪸ (k,K)
> 
>             10: (c,C) ⪸ (k,K)  iff
>                          ¬ (c,C) ≍ (k,K) ⋀
>                           c > k  ⋀
>                          ∄d ∈ concepts(K). (c > d ⋀ d > k  ⋀ d ≠ k)
> 
> 
>             Close Match:  (c,C) ≈ (k,K)
> 
>             The semantics of close match are under determined:  as a
>             bare minimum, we must define a similarity function  f ∈
>             (CONCEPT × CONCEPT → [0,1]), together with a threshold t
>             below which two concepts are not considered to be a match.
> 
>             11:    (c,C) ≈ (k,K) iff  ¬ (c,C) ≍ (k,K) ⋀
>                                          f(c,k) ≥ t   ⋀
>                                          ∄d ∈ concepts(K). f(c,d) > f(c,k)
> 
> 
> 
> 
>     -- 
>     *****************************************************
>     Stella Dextre Clarke
>     Information Consultant
>     Luke House, West Hendred, Wantage, OX12 8RR, UK
>     Tel: 01235-833-298
>     Fax: 01235-863-298
>     stella@lukehouse.org <mailto:stella@lukehouse.org>
>     *****************************************************
> 
> 


-- 
*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
stella@lukehouse.org
*****************************************************

Received on Monday, 8 February 2010 15:36:48 UTC