Re: data integration by mapping concept schemes

Hi Thomas,

Well again my only recommendation for reference to match your need would be the pattern with rdfs:range/owl:allValueFrom. Use that pattern in combination with any "grouping pattern" (i.e. similar to skos:inScheme/skos:ConceptScheme, *not* rdf:type/owl:Class) you see fit.

I really dislike making skos:inScheme a sub-property of rdf:type. This is amounts to declaring that a concept x is an instance of a concept scheme c, and I find that really disturbing. I can't really get my head around what the meaning could be in fact. To me it can only confuse SKOS users.


By the way note that
skos:ConceptScheme rdfs:subClassOf owl:Thing .
is already true. And it is true of every possible class (cf. "each user-defined class is implicitly a subclass of owl:Thing" [1]). So I'm not sure I understand the proposal that is based on this...

Cheers,

Antoine

[1] http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DefiningSimpleClasses


> 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 21:25:12 UTC