allow to do narrower-than hierarquies trees with indentation simple files

[GoogleCodeExporter]

Add the possibility of submitting an indented text file, which will create
a hierarchy of SKOS concepts doing narrower-than relations.

For example:

Label, Description
Car, medium of transportation
  SUV, ...
    Family_SUB,

will create:
SUV nt car
Family_SUB nt SUV

Original issue reported on code.google.com by ber...@gmail.com on 6 May 2009 at 8:55

[GoogleCodeExporter]

Allow only 1 parent or if label is repeated add a second parent ( not sure if 
SKOS
allows this )

Original comment by ber...@gmail.com on 6 May 2009 at 8:56

[GoogleCodeExporter]

I'll be looking into this along with issue 149.

Original comment by caru...@gmail.com on 30 Jun 2010 at 10:05

• Changed state: Accepted
• Added labels: Milestone-Beta1, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

What follows is a more precise example and specification for text contents that 
can be imported to create a SKOS vocabulary with hierarchical structure.

---------------------------------------------
# Empty lines are ignored.
# Lines starting with # are ignored.

# Lines of the form: <identifier> = <value>
# are parsed and interpreted as follows:

# URI for the ontology and namespace for its terms.
# By default, an ad hoc URI is assigned.
ontologyURI = "http://example.org/myont"

# Local name for the concept class:
class = "Foo"

# Properties for the class.
# Well-known properties can be indicated with their typical 
# denotation, eg., skos:preLabel:
skos:prefLabel = "My preferred label for Foo"

# String defining the hierarchical structure for the terms according to the
# indentation level determined by this string in the first column.
# By default, indentation is ignored.
indent.string = "  "

# The relation to use between the parent and the child when a non-empty 
# indent_string is indicated.
# By default, skos:narrower
indent.property = skos:narrower

# the separator character for the CSV contents below.
# By default, ",".
separator = ","

# Then, the actual CSV contents defining the terms:

# Header line indicates:
#  - first column: If the column name is "URI", then the values in this column
#    are used exactly as given for the URIs for the terms. Otherwise, the value
#    is used along with the namespase (ontologyURI) to compose the term URI.
#  - subsequent columns indicate the properties to be associated with each 
term.  
#    Well-known properties, eg., skos:preLabel, can be used, but others can be
#    defined as well.

# Subsequent lines define the terms themselves

ID             ,skos:prefLabel ,skos:definition           ,myProperty 
conceptA       ,concept A      ,concept A definition      ,my value for concept 
A
  conceptA1    ,concept A1     ,concept A1 definition     ,my value for concept A1
    conceptA1a ,concept A1a    ,concept A1a definition    ,my value for concept A1a
    conceptA1b ,concept A1b    ,concept A1b definition    ,my value for concept A1b
  conceptA2    ,concept A2     ,concept A2 definition     ,my value for concept A2
conceptB       ,concept B      ,concept B definition      ,my value for concept 
B
  conceptB1    ,concept B1     ,concept B1 definition     ,my value for concept B1
conceptC       ,concept C      ,concept C definition      ,my value for concept 
C

Original comment by caru...@gmail.com on 4 Aug 2010 at 5:56

• Changed state: Started

[GoogleCodeExporter]

Implemented.

MMI Portal 1.9.92.alpha (20100805160455)

See http://marinemetadata.org/mmiorrusrman/voc2skos

This functionality has been enabled via one more possible format for the 
registration of an external file. Now, besides the various formats supported by 
Jena (see issue #271), there is also a special file format accepted, 
"voc2skos", to do the conversion from a text file (in the format described in 
the previous comment) into SKOS.  Upon registration (regardless of the original 
format), the ontology is stored in "RDF/XML" in the back-end as usual.

Note that once registered, the ontology will continue to be handled in the 
"other" category for purposes of display (ie., not using any specific interface 
as is done with voc2rdf- or vine-created ontologies.

Of course, an interesting future feature is to provide an appropriate GUI for 
the generated SKOS vocabularies (including good visualization of the hierarchy 
of terms).

Original comment by caru...@gmail.com on 5 Aug 2010 at 11:05

• Changed state: Fixed