W3C home > Mailing lists > Public > public-swd-wg@w3.org > December 2007

Re: skos:related typing

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 26 Dec 2007 18:17:35 +0100
Message-ID: <47728CAF.2010709@few.vu.nl>
To: Bernard Vatant <bernard.vatant@mondeca.com>
CC: Dale Mead <dmead@nortel.com>, public-swd-wg@w3.org, public-esw-thes@w3.org

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 



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:47 UTC