AW: AW: [QB] Last Call document draft

Hi,

> The relevant well-formedness criterion is IC-19 [1] which expects
> that
> if the codeList is a skos:ConceptScheme then the concepts link to the
> scheme via skos:inScheme and if it is a skos:Collection then that
> should
> link to the concepts via skos:member.
With xkos, this looks different. I currently reuse it as follows:

I attach xkos:ClassificationLevels via skos:inScheme to the skos:ConceptScheme.

I attach an xkos:ClassificationLevel to skos:Concepts via skos:member.

Not sure whether this is the best way, but this is one way of defining hierarchies (skos:ConceptScheme) of levels (xkos:ClassificationLevel) of members (skos:Concept). IC-19 would throw an error, since it would assume xkos:ClassificationLevels to be the concepts used in the observations.

To help with the design, I have tried to create a summary of options of how to model coded dimensions:

* Use rdfs:range of class with instances
* Use qb:codeList with skos:ConceptScheme and define concepts via skos:inScheme (from skos:Concept)
* Use qb:codeList with skos:ConceptScheme and define hierarchy of concepts via skos:hasTopConcept (from skos:ConceptScheme) and skos:narrower (from each skos:Concept).
* Use qb:codeList with qb:HierarchicalCodeList and define hierarchy of resources via qb:hierarchyRoot (from qb:HierarchicalCodelist) and property defined from qb:HierarchicalCodeList by qb:parentChildProperty (from each resource)
* Use qb:codeList with skos:Collection and define concepts via skos:member (from skos:Collection)
* Use qb:codeList with skos:ConceptScheme and define hierarchy of xkos:ClassificationLevels via skos:inScheme (from xkos:ClassificationLevel) with hierarchy of concepts in the levels via skos:member (from xkos:ClassificationLevel) and skos:narrower (from each skos:Concept). <= This is the way I use to model hierarchies of levels of members.
* Use qb:codeList with skos:Collection and define hierarchy of xkos:ClassificationLevels via skos:member (from skos:Collection, i.e., nested collection) with hierarchy of concepts in the levels via skos:member (from xkos:ClassificationLevel) and skos:narrower (from each skos:Concept). <= This is one other way to model hierarchies of levels of members.

Best,

Benedikt

________________________________________
Von: Dave Reynolds [dave.e.reynolds@gmail.com]
Gesendet: Donnerstag, 7. März 2013 18:49
An: Benedikt Kaempgen
Cc: Government Linked Data Working Group
Betreff: Re: AW: [QB] Last Call document draft

Hi Benedikt,

On 07/03/13 17:19, Benedikt Kaempgen wrote:

> Larger feedback:
>
> ==10.2 Hierarchical code lists==
> * For OLAP on QB [1], I use hierarchy levels of increasing detail as first class citizens in the data, e.g., to give them a name such as "Product Brand". Therefore, I am using XKOS for representing hierarchy levels (xkos:ClassificationLevel, subclass of skos:Collection) [2].
> * Here, I would still use skos:narrower to define relationships between skos:Concepts.
> * However, I would connect those concepts via skos:member to separate xkos:ClassificationLevels, each having a xkos:depth, and would then connect those xkos:ClassificationLevels via skos:inScheme to the code list.
> * Also, I would not declare skos:topConcept but rather define the top concepts via an upmost level (depth 0 or 1).
> * I want to make sure that I still comply with the vocabulary and do "not use terms from other vocabularies instead of ones defined in this vocabulary that could reasonably be used".
> * Thus, my question: Can publishers still reuse XKOS together with QB? I think, we should allow and clarify this. For instance, this could mean to allow that skos:Collections are connected to a code list instead of using skos:hasTopConcept.

I agree that you should be able to use xkos with QB. I don't think it is
appropriate to specially call out xkos so the question is whether any
change is required in the current text.

We now explicitly allow skos:Collection as a qb:codeList (see the
owl:unionOf range declaration that was added to address ISSUE-39).

The relevant well-formedness criterion is IC-19 [1] which expects that
if the codeList is a skos:ConceptScheme then the concepts link to the
scheme via skos:inScheme and if it is a skos:Collection then that should
link to the concepts via skos:member.

I think that this allows your usage but if you think that needs to
change then now's the time to say!

[I'll address the editorial issues separately.]

Cheers,
Dave

[1] https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html#ic-19

Received on Friday, 8 March 2013 12:30:22 UTC