- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Wed, 26 Dec 2007 09:22:14 +0100
- To: Dale Mead <dmead@nortel.com>
- Cc: public-swd-wg@w3.org, public-esw-thes@w3.org
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? > > > > > > > > -- *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@mondeca.com <mailto:bernard.vatant@mondeca.com> Blog: Leçons de Choses <http://mondeca.wordpress.com/>
Received on Wednesday, 26 December 2007 08:22:37 UTC