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?
>>
>>
>>
>>
>>
>>
>>
>>   
>

Received on Wednesday, 26 December 2007 17:48:26 UTC