Re: Ordering concepts in a Tree display

Hi guys,

I'm wondering if it would be useful to define a few simple test cases here. For
each test case, you could give a tree display that you want to be able to
generate, then give one or more possible options for the RDF data that you
think is sufficient to generate the display.

E.g., an example test case (off the top of my head)...

Tree to display:

---
aeroplanes
.<aeroplanes by number of wings>
..monoplanes
..biplanes
..triplanes
.<aeroplanes by method of propulsion>
..propeller aeroplanes
..jet aeroplanes
---

Possible RDF representation (turtle):

---
<A> a skos:Concept; skos:prefLabel "aeroplanes"@en;
    skos:narrower <B>, <C>, <D>, <E>, <F>.
    
<B> a skos:Concept; skos:prefLabel "monoplanes"@en.
<C> a skos:Concept; skos:prefLabel "biplanes"@en.
<D> a skos:Concept; skos:prefLabel "triplanes"@en.
<E> a skos:Concept; skos:prefLabel "propeller aeroplanes"@en.
<F> a skos:Concept; skos:prefLabel "jet aeroplanes"@en.

<G> a skos:OrderedCollection; 
    rdfs:label "aeroplanes by number of wings"@en; 
    skos:memberList ( <B>, <C>, <D> ).
    
<H> a skos:OrderedCollection; 
    rdfs:label "aeroplanes by method of propulsion"@en; 
    skos:memberList ( <E>, <F> ).
---

If it's not immediately obvious that the RDF data is sufficient to generate
the display, then you might also want to give an outline of the algorithm
you'd use to render the tree, e.g. (pseudocode):

---
lang = "en"
start = <A>
tree = new Tree()
root = new TreeNode(start.getPrefLabel(lang))
tree.setRoot(root)
collections = new Set()
for x in start.getNarrower():
    # find any SKOS collections in which x appears
    collections.addAll(x.getParentCollections())
# now render first level children using collection labels
for c in collections:
    n1 = new TreeNode(c.getLabel(lang))
    root.addChild(n1)
    # now render second level children using member concept preflabels
    for x in c.getMemberList():
        # check x is really narrower than <A>
        if x in start.getNarrower():
            n2 = new TreeNode(x.getPrefLabel(lang))
            n1.addChild(n2)
# tree is now built, call render
tree.render()
---

There are a couple of interesting things that emerge from trying to write
an algorithm for this test case.

First, this algorithm clearly wouldn't deal with nested collections, or a
mixture of narrower concepts where some are members of a collection and some
are not - which would lead on to further test cases to probe these issues.

Second, attempting to write this algorithm made me realise that actually
the RDF data given are *not* sufficient to deterministically generate the
required display, because the data do not specify in what order the first
level children should be rendered. I.e., both:

---
aeroplanes
.<aeroplanes by number of wings>
..monoplanes
..biplanes
..triplanes
.<aeroplanes by method of propulsion>
..propeller aeroplanes
..jet aeroplanes
---

...and:

---
aeroplanes
.<aeroplanes by method of propulsion>
..propeller aeroplanes
..jet aeroplanes
.<aeroplanes by number of wings>
..monoplanes
..biplanes
..triplanes
---

...could be generated from these data, and you would need additional data
to rule one out.

Anyway, the point of this email was not to deal with a specific case,
but to suggest a method by which different RDF representations could be
discussed and evaluated against each other. For each test case and possible
RDF representation, the two questions you would want to ask are: (1) are
the RDF data sufficient to deterministically generate the required tree
display? and (2) how hard is the rendering algorithm to design?

Hope that helps,

Alistair

On Mon, Jan 24, 2011 at 10:47:40AM +0100, Jakob Voss wrote:
> On 20.01.2011 18:57, Christophe Dupriez wrote:
> 
> >Do you think we need a Collation definition if we have an optional
> >sortKey property? The collating process may be more a question of
> > process than one of data?
> 
> With a Collacation ontology you could define and share the process
> that dynamically calculates your sortKey. But sure we can start with
> a simple sortKey property and later add best-practice methods how to
> generate it. I am not fully comfortable with having it as property
> of the concept, but the triple-model of RDF does not let us do
> better without reification. Whe should only agree on:
> 
> 1. The URI of the sortKey property
> 2. The domain of the property (literal with integer datatype?)
> 3. Whether a resource can have more than one sortKey (similar to
> http://www.w3.org/TR/skos-reference/#S14 for prefLabel).
> 
> Jakob
> 
> -- 
> Jakob Voß <jakob.voss@gbv.de>, skype: nichtich
> Verbundzentrale des GBV (VZG) / Common Library Network
> Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
> +49 (0)551 39-10242, http://www.gbv.de
> 

-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo@gmail.com
Tel: +44 (0)1865 287669

Received on Monday, 31 January 2011 17:52:48 UTC