RE: skos:related typing

If this can help, also in FAO we are specialising the RT relationships of the
AGROVOC thesaurus, and we have adopted similar approach: to create a
hierarchical tree of relationships, in top of which there is the traditional
RT (skos:related).
Attached a screenshot of the organized relationships.

If needed I can provide a document describing our approach.

Regards
Margherita

-----Original Message-----
From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
Behalf Of Antoine Isaac
Sent: 26 December 2007 18:18
To: Bernard Vatant
Cc: Dale Mead; public-swd-wg@w3.org; public-esw-thes@w3.org
Subject: Re: skos:related typing



Hi Dale, Bernard,

I support Bernard's proposal. this is how I would have done it, also. The
SKOS Primer we're working on now (first bake in coming days!) has a 
small section which encourages that kind of specialization of the SKOS 
model.

Cheers,

Antoine

PS: and a happy new year to all of you :-)
>
> Hi Dale
>
> At first sight, and unless I miss something more subtle, your problem
> could be managed simply using subproperties of skos:related.
> You will have for example
>
> ex:compatibleWith   rdfs:subPropertyOf      skos:related
>
> This kind of declaration allows your application to handle any
> specific functionalities you want to attach to ex:compatibleWith, and 
> a vanilla skos application would handle it as any skos:related property.
>
> Bernard
>
> Dale Mead a écrit :
>> I have been lurking on this list for a few months trying to catch up 
>> with the discussion.  My apologies in advance if my question is 
>> something that has been dealt with in previous discussions that I 
>> haven't found.
>>
>> Background for my question:  We are a running a production 
>> semantic(ish) engine that maintains an enterprise thesaurus driving 
>> cataloging and facetted navigation for knowledge management and our 
>> corporate intranet. We currently have 45K Concepts with 500K+ 
>> documents associated with those concepts and have been in production 
>> since 1997.
>>
>> As part of an enterprise rearchitecture, we are looking at the 
>> feasibility of using SKOS as a vehicle for providing thesaural 
>> information to other enterprise systems outside of the KM, DM, and 
>> web domains as a web service.
>>
>> Most of what I see in SKOS maps very cleanly into what we have been 
>> doing for the last 10 years with the differences mainly being in what 
>> we called things and, of course, in that we aren't currently 
>> expressing in XML because XML was not yet a standard in 1997. The 
>> biggest delta is with skos:related.  In my context, I need to be able 
>> to track not just that there exists a relationship, but what the 
>> nature of that relationship is.  An easy example out of many:
>>
>> Product A is our product.  Products B and C are products of a 
>> competitor.  Product A is related to Product B as a competing product 
>> (which allows us to do things like put competitive intelligence 
>> materials about B on A's intranet page).  Products A and C are 
>> related because Product A is compatible with Product C.  That is, we 
>> can sell our Product A into an established Product C environment.  
>> The information that I want to give the sales person is our story 
>> about that compatibility rather than competitive information about 
>> Product C.  I can easily come up with a couple of dozen other 
>> situations where I want typed relationships.
>>
>> My inclination is that I want to put an additional rdf attribute in 
>> the skos:related element to indicate the type of relationship.  
>> However, if I have been reading this discussions on this list 
>> correctly, I shouldn't be adding additional formal attributes within 
>> skos elements.  (Is this a correct understanding?)
>>
>> Has this issue been addressed within the SKOS discussions?
>>
>>
>>
>>
>>
>>
>>
>>   
>