W3C home > Mailing lists > Public > public-esw-thes@w3.org > August 2012

Re: data integration by mapping concept schemes

From: Thomas Bandholtz <thomas.bandholtz@innoq.com>
Date: Tue, 28 Aug 2012 22:56:07 +0200
Message-ID: <503D3067.5030801@innoq.com>
To: Antoine Isaac <aisaac@few.vu.nl>, "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Hi Antoine,

I have thought about such a solution before, but I never got down to the
real code.
Thank you for these helpful code examples.

What you describe is kind of an "adapter" between different patterns of
referring to subsets of concepts.

Referring to subsets of concepts from everywhere is the most general use
case of SKOS.
Allmost nothing else matters here. I am not talking about ontology, just
about concept-based terminology to be referrenced by observation records
(Data Cubes).

Given this, SKOS (in real life, at large) requires such adapters to be
referenced, and referrers may find this rather awkward.

I did not vote so much for subclasses of skos:Concept as a possible
solution.
I did vote for a single recommended pattern for the reference, as this
would be helpful to support the most general use case.

When we talk about subclasses of skos:Concept as a possible
recommendation, I would start with adding a single statement:

skos:ConceptScheme rdfs:subClassOf owl:Thing .

Maybe this is even there - I did not check this. Anyway, the given
schema does make the most of such a statement.
This does not keep you from attaching all the domain specific properties
you have mentioned  to instances of this specific kind of thing.

Those instances need to be subclasses of skos:ConceptScheme, and all
local schemes all over the world need to be defined als subclasses of
skos:ConceptScheme.

By the statement above, the reasoner can infer this from the traditional
statement:

ex:myScheme a skos:ConceptScheme .

The class tree in this example.

owl:thing
  skos:ConceptScheme
    ex:myScheme


Then I would make skos:inScheme subProperty  of rdfs:type.

I think that we are allmost done ?

Adding something like this to the standard would cease any need for
adapters, just by a few statements in the schema.


May be a third opinion would be welcome?

Best regards,
Thomas


Best regards,
Thomas

Am 28.08.2012 21:45, schrieb Antoine Isaac:
> Hi Thomas,
>
> I am not 100% certain I get the constraints that you have on
> expressing "mappings" in your scenario.
>
> You could have an OWL-based solution:
> 1. Define the set of concepts that belong to either concept scheme
> (collection, whatever)
>   some:CityOrArea owl:equivalentClass  [
>         owl:intersectionOf  ( skos:Concept
>                               [ rdf:type            owl:Restriction ;
>                                 owl:onProperty      skos:inScheme ;
>                                 owl:someValuesFrom  [ owl:oneOf  (
> a:cities b:areas )]  ]
>                             )
>       ] .
> 2. If you want to go one step beyond and "populate" a new concept
> scheme, you can create another axiom
>   some:CityOrArea rdfs:subClassOf [ rdf:type            owl:Restriction ;
>                                 owl:onProperty      skos:inScheme ;
>                                 owl:someValuesFrom  [ owl:oneOf  (
> c:citiesAndAreas )]  ]
> I think that should do it. In any case I know there's something in OWL
> that does it.
>
>
> As an alternative, you can "populate" directly your concept scheme
> with skos:inScheme statements using a SPARQL construct:
> CONSTRUCT { ?c  skos:inScheme c:citiesAndAreas }
> WHERE
>  {
>     { ?c skos:inScheme a:cities } UNION  { ?c skos:inScheme b:areas }
>  }
>
> Does any of this address your need?
>
> Cheers,
>
> Antoine
>
>
>> Hi Antoine,
>>
>> my use case is data integration.
>>
>> Dataset A has defined concept scheme (or collection or subclass)
>> a:cities as a value set.
>> Dataset B has defined concept scheme (or collection or subclass) b:areas
>> as a value set.
>>
>> Now I want to have some agent X to query both (and further) datasets.
>> I want a query builder where users can pick cross-dataset search
>> conditions from a list.
>>
>> To support this, X defines a concept scheme x:location which is the set
>> union of a:cities and b:area.
>> Each concept in x:location will have skos:inScheme a:cities and/or
>> b:area, sure.
>> The set of referred concept schemes can be inferred from this.
>> But I would like to describe the intention in one explicit statement.
>>
>> This is why I am looking for a mapping relation between such subsets of
>> concepts.
>>
>> Best regards,
>> Thomas
>>
>> Am 22.08.2012 21:15, schrieb Antoine Isaac:
>>> (3)
>>> I'm not sure I get the question. If they exist, such mapping
>>> properties could be very difficult to semantically define. Would a
>>> concept scheme be broader, equivalent, narrower than another one?
>>> Rather, I'd say that the property you're after indicates that some
>>> concepts from these two concept schemes are connected. For this I
>>> think one could use general linkage properties between datasets, such
>>> as voiD's linksets [2].
>>
>>
>
>


-- 
Thomas Bandholtz
Principal Consultant

innoQ Deutschland GmbH
Krischerstr. 100, 
D-40789 Monheim am Rhein, Germany
http://www.innoq.com
thomas.bandholtz@innoq.com
+49 178 4049387

http://innoq.com/de/themen/linked-data (German)
https://github.com/innoq/iqvoc/wiki/Linked-Data (English)
Received on Tuesday, 28 August 2012 20:56:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:19 UTC