Broader and narrower in Vocab

[Bernard Vatant]

Tony

> And an excellent lot of comments, they are. Many thanks, Bernard.
>   
You're welcome. Since one among many errors in my life quite a while ago 
(say, 35 years ago) was not to be bold enough to switch from maths to 
astronomy for good, I've been feeling like I've an ancient debt to this 
science and community, so if the time I've past struggling with those 
issues can be useful here ... At least to tag a few paths with "here be 
monsters". :-)
>>> concept to belong to more than one broader concept, but this is not,
>>> AFAIK, possible in SKOS.
>>>
>>>       
>> Oh, yes it is. SKOS allows multiple broader for one concept, and many
>>     
>
> Right. The only examples I looked at only had the one and I've not yet got
> to grips with ThManager to figure out how to do things.
>   
Hmm. Not sure ThManager handles multiple braoder properly ... Not 
checked, actually.
> Is there a decent tool for constructing SKOS vocabularies? Even better,
> is/are there web-based interface(s) we could use for constructing and/or
> viewing these vocabularies?
>   
Mondeca ITM :-) .  It's neither freeware nor open source, though. ;-)

Seriously now, the lack of proper simple and efficient SKOS editor(s) is 
really a pain in the neck at the moment.
See http://esw.w3.org/topic/SkosDev/ToolShed. If it's not there, it's 
nowhere. But there is not much.
Most of the time, given their simple structure, SKOS vocabularies are 
currently produced by migration of existing vocabularies in whatever 
text or proprietary format. Not difficult actually.
Maintenance is another story.

>> See e.g. how multihierarchy is handled in the Web interface of the
>>     
>
> I assume that that way of representing the multiple trees is just that
> organisations chosen way. Ie, you could choose whichever way best
> represented your own knowledge (or multiple ways I guess).
>
>   
Of course. Storing vocabularies is one thing, query, display, browse ... 
is another story. Now actually, when you look at data bases you can 
access via a variety of Web services and interfaces, things can be 
stored in any internal model. You don't need to have a triple store 
under the hood to output RDF. See e.g., GeoNames 
(http://www.geonames.org). It had a very classical data base with a 
range of XML/JSON webservices. At some point someone in the SW community 
asked for RDF Web services. I set up an OWL/SKOS model of the data, and 
the RDF output was set up in no time. But GeoNames has no RDF data under 
the hood, it's generated at query time.
>> There are different solutions to handle multiple hierarchies, one being
>> to qualify ("color") the b/n links so that the multi-hierarchical graph
>> is considered as the entangling of distinct graphs, in each of one
>>     
>
> That sounds the best way forward. I assume it is best to enumerate the
> relationship types that each graph will handle up front?
>   
Hmm. Not sure I undersatnd the question, but I would say "no". You can 
have distinct but entangled graphs using the same relationship type.
> What would a set of SKOS declarations using more than one colour of graph
> look like for astro-type terminology?
>   
You can use the general notion of RDF "named graphs", which allow to 
indicate to which graph(s) any triple belongs to.
>> please keep distinct the URI for the SKOS concept and the URI for the
>> equivalent/similar/matching OWL class, so that you can identify very
>> distinctly, e.g.,
>>     
>
> I bow to your greater knowledge
>   
I'm just maybe standing on a higher pile of errors.  :-)

Bernard

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant at mondeca.com <mailto:bernard.vatant at mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>