- From: José Ramón Pérez Agüera <jose.aguera@gmail.com>
- Date: Fri, 18 Dec 2009 11:18:47 -0500
- To: Christophe Dupriez <christophe.dupriez@destin.be>
- Cc: Simon Spero <ses@unc.edu>, public-esw-thes@w3.org
Hi Christophe, You are right, it is always very good to confront our ideas with the community :-) I have a demo of my implementation here http://karya.nescent.org:9090/home.html (it is a very beginning demo). Our project is focused on how to design and develop a vocabulary server based on SKOS. Our idea is to develop a open source library which might be useful for the community to implement manual and automatic indexing systems. We have to be able to integrate any vocabulary in this server. The problem is how to represent a lot of different vocabularies, with different and specific features, in the same system. My first idea was to implement something similar to Simon's proposal, but, you know, the number of different features is infinite if we take into account that any different organization might implement different features for their vocabularies depending their specific needs. Now I'm working in a different idea, instead of create a new block in the semantic web stack (RDF->OWL->SKOS->Whatever) I'm working in a basic representation based only on RDF, where any vocabulary, or even ontology is represented using only RDF. I'm using a IR approach to do that, based on inverted index structure to implement a system flexible enough to represent any vocabulary or even ontology (Actually I'm working also with dbpedia). A good example of this is SEMPLORE system: http://www.aifb.uni-karlsruhe.de/WBS/dtr/papers/semplore.pdf Actually, this is related also with the discussion about how to represent dbpedia with SKOS. I guess that the problem is the different ways to use the information. I'm my case where concept retrieval is very important maybe the solution is not go up in the semantic web stack but go down, I don't know :-) thank you very much for your time best jose 2009/12/18 Christophe Dupriez <christophe.dupriez@destin.be>: > Hi José! > > Standard bodies and communities have difficulties to adapt their mindtrack > to individual situations and understandings. > In a way, each of us is "exercizing" its mind with the diverse problems > submitted. Then the reuse of ideas follows unexpected paths... > > My suggestion would be "do not loose useful information" (code it in any > precise way you need): from complete information, > it is always possible to derive an "adapted" (and less precise) version for > whatever standard exists at the time you really export. > > BUT, this being said, confront your ideas with the community to be sure you > do not miss important concepts in your "private" design! > > Have a nice w.e. > > Christophe > > José Ramón Pérez Agüera a écrit : >> >> Hi Simon, >> >> I'm sorry for late reply and thank you very much for your very good >> answer. My problem is that I would like to avoid to extend SKOS to >> represent my thesaurus. I have seen similar solutions in the >> literature and I think that the main problem extending SKOS is that we >> lost interoperability, since we create new elements which are not >> represented in SKOS standards. >> >> My system is working with different kind of vocabularies so I need to >> be able to describe any vocabulary in the same way, in order to have a >> only way to search, browse in my bag of concepts. I would like to >> represent my thesaurus without any extension and without lost >> information, but I guess that this is not possible :-) >> >> Anyway, thank very much for your answer >> >> best >> >> jose >> >> 2009/12/14 Simon Spero <ses@unc.edu>: >> >>> >>> 2009/12/14 José Ramón Pérez Agüera <jose.aguera@gmail.com> >>> >>>> >>>> Hi all, >>>> I have a thesaurus that I want export to SKOS format. However, this >>>> thesaurus defines following relationships between concepts: [see below] >>>> >>>> My first idea was to map all these relationships with skos:related, >>>> however my thesaurus is a geographical thesaurus, therefore >>>> relationships >>>> like capital of are important. >>>> >>>> My question is: Is SKOS Core expressive enough to represent these >>>> relations in some way or I should use OWL to represent this thesaurus >>>> like >>>> an Ontology? >>>> >>> >>> Hi José, >>> >>> There are a lot of issues that may nudge you one way or the other, but if >>> you're looking to use the thesaurus as a Knowledge Organizing System, >>> rather >>> than a Knowledge Representation System, SKOS can be extended to represent >>> these relations in a way that will be backwards compatible with SKOS >>> Core. >>> The downside is that you may have to do a lot of contorting if you want >>> to >>> express more sophisticated constraints (e.g. a Country must have a >>> capital; >>> the capital must be a city; the city must be contained within the >>> country, >>> etc). [I am punning between Subject and Object for simplicity]. >>> >>> Most of the properties are associative, and would thus be sub-properties >>> of >>> skos:related. Sub-properties of skos:related do not have to be symmetric >>> themselves, so you can use inverted properties to represent this so that >>> a >>> reasoner can infer the appropriate inverse link. >>> >>> There is one relationship in the list that may be hierarchical rather >>> than >>> associative; if it's a specialization of the partitive relationship >>> (BTP/NTP), then you can define it as a sub-property of broaderPartitive >>> or >>> broader. Otherwise, you can just treat it as associative. >>> >>> Simon >>> >>> Symmetric Relationships >>> >>> related to >>> >>> ObjectProperty: relatedTo >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> ally of >>> >>> ObjectProperty: allyOf >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> historical connection >>> >>> ObjectProperty: historicalConnection >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> distinguished from >>> >>> ObjectProperty: distinguishedFrom >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> adjacent to >>> >>> ObjectProperty: adjacentTo >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> coextensive with >>> >>> ObjectProperty: coextensiveWith >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> possibly identified as >>> >>> ObjectProperty: possiblyIdentifiedAs >>> Characteristics: >>> Symmetric >>> SubPropertyOf: >>> related >>> >>> Asymmetric Relationships >>> >>> capital of >>> capital is >>> >>> ObjectProperty: capitalOf >>> InverseOf: >>> capitalIs >>> SubPropertyOf: >>> related >>> >>> ObjectProperty: capitalIs >>> InverseOf: >>> capitalOf >>> SubPropertyOf: >>> related >>> moved from >>> moved to >>> >>> ObjectProperty: movedFrom >>> InverseOf: >>> movedTo >>> SubPropertyOf: >>> related >>> >>> ObjectProperty: movedTo >>> InverseOf: >>> movedFrom >>> SubPropertyOf: >>> related >>> >>> >>> successor of >>> predecessor of >>> >>> ObjectProperty: successorOf >>> InverseOf: >>> predecessorOf >>> SubPropertyOf: >>> related >>> >>> ObjectProperty: predecessorOf >>> InverseOf: >>> successorOf >>> SubPropertyOf: >>> related >>> >>> member of >>> member is >>> >>> ObjectProperty: memberOf >>> InverseOf: >>> memberIs >>> SubPropertyOf: >>> related >>> >>> ObjectProperty: memberIs >>> InverseOf: >>> memberOf >>> SubPropertyOf: >>> related >>> >>> >>> >> >> >> >> > > -- Jose R. Pérez-Agüera Clinical Assistant Professor Metadata Research Center School of Information and Library Science University of North Carolina at Chapel Hill email: jaguera@email.unc.edu Web page: http://www.unc.edu/~jaguera/ MRC website: http://ils.unc.edu/mrc/
Received on Friday, 18 December 2009 16:20:21 UTC