OWL over RDF over XML over metadata over data partially representing reality

Hi Johan!

One may be worried that we add layers after layers:
Real --> Structured data --> Extensible Markup --> Ressource Description 
Framework Vocabulary --> Ontology reasoner...
If we could agree on semantic, then the standard would be nearer from 
common needs and layers could be removed for common processing chores...

If a OWL processor is needed, may be I should consider seriously 
TopicMaps... or SQL! After this "half joke":

My main current problem being SKOS validation workflow where I have 
meta-meta-data (data about approval process of metadata), annotating RDF 
relations currently obliges to reify them.
The other solution could be to add an XML namespace (to define an XSD 
additional to RDF XSD) to describe reviewing data (to not consider 
meta-meta-data as a part of meta-data).
Anyone has an experience with RDF overloading? for collaborative 
reviewing of RDF triples?
I am still looking for (MSc/PhD student / research team ) effort sharing 
for:
http://www.askosi.org/maintenance.pdf

Have a nice day!

Christophe



Le 7/02/2011 10:59, Johan De Smedt a écrit :
>
> Hi Christophe,
>
> This may go beyond the extension of SKOS and ISO 25964-1 is indeed 
> more complete in modeling thesauri.
>
> However, I think of 2 possible ways to make extensions to SKOS.
>
> For SKOS, reification may be used or OWL2 annotations
>
> - Define your annotation property/ies (e.g. my-annotation:siblingKey)
>
> - Assign the key (together with potential other annotations) to the 
> relation using:
>
> owl:Axiom [
>
>    owl:annotatedSource <concept_a> ;
>
>    owl:annotatedTarget <concept_b> ;
>
>    owl:annotatedProperty <skos:broader> ;
>
>    my-annotation:siblingKey "key-value" .
>
>   ]
>
> skos:OrderedCollection may be another way to get items ordered.
>
> In this case you also need some extensions
>
> 1- to determine when to use a particular collection.
>
>   e.g. for sorting the narrower terms of concept <a>,  a
>
> <collection-x> example:sortNarrowerFrom <a> .
>
>         could be used.
>
> 2- identify the sorting algorithm used.
>
>   e.g. collections could be typed or use other properties 
> (example:sortAlgorithm).
>
> Such a property may be added to the collection
>
> Kind Regards,
>
> *Johan De Smedt *
>
> /Chief Technology Officer/
>
> //
>
> mail: johan.de-smedt@tenforce.com <mailto:johan.de-smedt@tenforce.com>
>
> mobile: +32 477 475934
>
> home page: http://www.tenforce.com <http://www.tenforce.com/>
>
> mail-TenForce
>
> *From:*public-esw-thes-request@w3.org 
> [mailto:public-esw-thes-request@w3.org] *On Behalf Of *Christophe Dupriez
> *Sent:* Monday, 07 February, 2011 09:35
> *To:* Aida Slavic
> *Cc:* Skos
> *Subject:* Re: Ordering concepts in a Tree display / possibly more 
> than a sort key
>
> Hi!
>
> If SKOS community wants to go further than one concept attribute for 
> what I would propose to call a "siblingKey" (a value used to sort 
> sibling concepts), an attribute to the broader relation is therefore 
> needed.
> This would be easy in XML (ISO 25954 but I do not see any ordering 
> information in the HierarchicalRelationship element) or with TopicMaps 
> but it requests reification of the RDF relation in SKOS.
>
> Knowing other problems (data about approval work-flow for relations 
> for instance), may I suggest starting the definition of SKOS-XR 
> (eXtended Relations) to open the design space to this kind of 
> enhancement ?
> Who has the "authority" (interest!) to manage such a project?
>
> Have a nice day!
>
> Christophe
>
> Le 6/02/2011 20:21, Aida Slavic a écrit :
>
> Hi,
>
> A bit from classification perspective...The order of foci in an array 
> is carefully observed and rigorously maintained in classification schemes.
> Ranganathan summarised devices used across classification schemes as 
> follows:
> - chronological (evolutionary) e.g. systematic botany, zoology
> - geographical (e.g. subdivision of art style by place, subdivision of 
> history by place) -  in faceted classifications this is achieved by 
> using facet of place
> - subject device (forming a facet in relation to a specific defined 
> property or by relation/dependence to a subject e.g. subdivision of 
> visual art by subject, subdivision of economics by industries)
> - alphabetical
> - enumeration
>
> Classification schemes combine all of the above devices. The purpose 
> of these rules is to reduce the size of a schedule (avoiding 
> enumeration) and secure conformity with respect to canons of 
> consistent sequence, helpful sequence, mnemonics, hospitality in 
> array, hospitality in chain. Hence the order of ideas is very 
> carefully determined. We fix this order in schemes in two ways that 
> always guarantee a logical and systematic (semantic) order mechanically:
>
> (1) through a notational system (as Joe Tennis mentioned earlier), 
> decimal and expressive notations using letters, numerals and 
> punctuation signs are designed in such a way that classes will always 
> fall in a desired meaningful order. Faceted or syntactical expressive 
> notational systems will also handle the correct ordering of complex 
> coordinated expressions.
> For instance, what should be ordered first?:
> a  notation expressing /Italian literature-18th century/ or /Italian 
> literature-poetry-18th century/,
> or a notation expressing/Italian literature - poetry - in Switzerland 
> -19th century/
> or /Italian literature - literary criticism/.
> There is obviously a sense of hierarchy here and sense of a general to 
> specific order that has to be preserved.  Rules for ordering of 
> notations are called  'filing rules'. These rules are established and 
> interpreted intellectually and it is often the case that they cannot 
> be supported by computer programs unless additionally coded.
>
> However: We cannot rely 100% on notation to order classes, handle 
> hierarchy or parse facets in all classification schemes or indeed use 
> notation for mechanical ordering by computer programs - at least not 
> without additional coding. It is also important not to confuse 
> classification structure with the type of notational system used in a 
> certain system. Reasons:
> Faceted classifications do not always have a 'faceted notation'. A 
> typical example is Bliss Bibliographic classification (a faceted 
> classification proper) - not only does it not have a hierarchically 
> expressive or facet expressive notation but this scheme itself may 
> represent classes as coordinated, when these are logically subsumed. 
> Bliss notation supports building of complex classes but once built 
> notation cannot be parsed (i.e. the system is 'synthetic' but not 
> 'analytic') - the advantage of this approach is simpler notational 
> device that  can be ordered mechanically as it does not contain 
> 'syntax symbols'. In addition,  classifications with otherwise 
> hierarchically expressive decimal notations (e.g. 531.1 is subclass of 
> 531 and 531 is subclass of 53) may also occasionally purposefully or 
> entirely accidentally fail to express a concept hierarchy (examples of 
> these can be found in Dewey, UDC, Colon Classification, Library of 
> Congress Classifications). One can chose either to have simple 
> ordering device  i.e. semantically void notation or notation that is 
> expressive and holds full information of hierarchy and syntax and can 
> be parsed but requires some input to make it work online. 
> Classification designers often try to find a middle solution depend of 
> the purpose of the system
>
> (2) in classification management databases for analytico-synthetic 
> systems we have to  'translate' sequence and filing order rules into 
> something similar to 'sortKey' described by Mike Collett below, 
> because of the fact that notational expressions using a combination of 
> letters, numerals and punctuation symbols as facet indicators cannot 
> be correctly sorted automatically by any of the standard character 
> coding tables.
> It is up to individual database management tools to solve this. For 
> instance, the UDC management system translates notation into special 
> codes that ensure both: accurate ordering and parsing of UDC complex 
> numbers by programs. For this we use a set of algorithms handling UDC 
> specific ordering rules. In addition to this we also maintain a 
> separate hierarchy code which captures BT/NT relationships as a single 
> sequence (across 68,000 classes) - this help us manage hierarchical 
> relationships independently from notation. With each annual UDC update 
> the hierarchy codes are 'refreshed'.
> UDC notation 37.015 Special pedagogic sciences - when coded looks as 
> follows 37.q15.-
> [This notation consist of two numbers 37 Education and special 
> auxiliary number .015 Special pedagogic science, .0  transformed into 
> .q is a facet indicator meaning the the this concept is of a certain 
> kind and can be combined based on a certain set of rules.
>
>
> What may be the main issue is that in exchanging or at the user end 
> classifications the place for sorting, filing or hierarchy codes is 
> not envisaged.
>
>
> Kind regards
>
> Aida
>
>
> On 14/01/2011 16:09, Mike Collett wrote:
>
> We use a sortkey
> eg<zthes:termNote label="sortKey">13</zthes:termNote>
>   
> We have found that this has been mostly OK as a single key within a concept
> scheme (vocabulary) and we can manage different sortkeys for different
> concept schemes.
>   
> By default we display alphabetically by the preferred label of the user's
> preferred language (set by browser or computer settings) if it exists, if
> not then in English if it exists, if not then by the first preferred label.
>   
> Some polyhierarchies need to have a concept in a different order in
> different parts of the tree. Then the relationship needs to hold the
> sortkey.
>   
> In Zthes type encoding this is easy
> eg
> <relation>
> <relationType>BT</relationType>
> <termId>xyz:1234</termId>
> <termSortkey>13</termSortkey>
> </relation>
>   
> Not sure how to do this in SKOS.
>   
> The effect could be
> Vehicles
>   NT (sortkey 1) Single wheeled vehicles
>   NT (sortkey 2) Bicycles
>   NT (sortkey 3) Tricycles
>   NT (sortkey 4) Four wheeled vehicles
>   NT (sortkey 5) Vehicles with more than 4 wheels..
>   
> Popular vehicles
>   NT (sortkey 1) Cars
>   NT (sortkey 2) Motorbikes
>   NT (sortkey 3) Bicycles
>   NT (sortkey 4) Skateboards
>   
> With Bicycles needing two different sortkeys.
>   
> Cheers
> Mike 7:-D
> -----------
> Mike Collett
> Vocabulary Management Group
> +44 7798 728 747
> ------------
> www.vocman.com  <http://www.vocman.com>
> mike@vocman.com  <mailto:mike@vocman.com>
>   
>   
>   
>
>     From: Christophe Dupriez<christophe.dupriez@destin.be>  <mailto:christophe.dupriez@destin.be>
>
>     Organization: DESTIN inc. SSEB
>
>     Date: Fri, 14 Jan 2011 12:56:08 +0100
>
>     To:<public-esw-thes@w3.org>  <mailto:public-esw-thes@w3.org>
>
>     Subject: Ordering concepts in a Tree display
>
>     Resent-From:<public-esw-thes@w3.org>  <mailto:public-esw-thes@w3.org>
>
>     Resent-Date: Fri, 14 Jan 2011 11:57:37 +0000
>
>       
>
>     Happy New Year to all the Simple Knowledge Organization Systems workers!
>
>       
>
>     Does anyone have designed a way to specify concept ordering when
>
>     displaying a tree of concepts?
>
>       
>
>     Usually, alphabetical ordering is the best to display narrower concepts
>
>     of a given concept.
>
>     But sometimes (for instance, with historical period), there is "natural"
>
>     ordering of concepts which is much better.
>
>     I would like to add a field with the ordering criteria (stronger than
>
>     the prefLabel in the user language).
>
>       
>
>     Anyone has done something for this so I do not reinvent the wheel:
>
>       
>
>     Vehicles
>
>     NT Single wheeled vehicles
>
>     NT Bicycles
>
>     NT Tricycles
>
>     NT Four wheeled vehicles
>
>     NT Vehicles with more than 4 wheels...
>
>       
>
>     Wishing you a very nice w.e. !
>
>       
>
>     Christophe
>
>       
>
>   
>   
>   
>