Re: AW: AW: [QB] Last Call document draft

Benedikt,

Let me summarize this in a slightly different way.

You have four different options for specifying the allowed dimension values of a coded property:

1. All instances of a given rdfs:Class (via rdf:type).
2. All skos:Concepts in a given skos:ConceptScheme (via skos:inScheme).
3. All skos:Concepts in a given skos:Collection or its subcollections (via skos:member).
4. All resources that are roots, or children of a root, of a qb:HierarchicalCodeList.

We support so many different options because we want to enable and promote re-use of existing structures expressed in SKOS, RDFS, XKOS, or in fact arbitrary other vocabularies. If you don't have an existing structure, then we recommend SKOS (option 2) as a sensible default.

Now, if you also want to express hierarchical relationships between the dimension values, then this affects which of these options you can use.

If you have no hierarchy, you can use any of them.

If your hierarchy is expressed with skos:broader/narrower links between skos:Concepts, then 2 is a particularly natural fit, and 3 is a good fit if the collection is in fact an xkos:ClassificationLevel (allowing you to calculate aggregates for any levels further up in the same classification). 1 and 4 don't really make sense in that case.

If your hierarchy is expressed with some other property, then you need to use option 4 and describe the hierarchy as a qb:HierarchicalCodeList.

More inline.

On 8 Mar 2013, at 12:29, Benedikt Kaempgen wrote:
> 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

Yes. This is one of the four options I'd recommend.

> * Use qb:codeList with skos:ConceptScheme and define concepts via skos:inScheme (from skos:Concept)

Yes. This is another option I'd recommend -- number two.

> * Use qb:codeList with skos:ConceptScheme and define hierarchy of concepts via skos:hasTopConcept (from skos:ConceptScheme) and skos:narrower (from each skos:Concept).

No.

If you do this, only the top level concepts will be allowed as dimension values.

skos:hasTopConcept implies skos:inScheme. So, if you have RDFS entailment, your top concepts become allowed dimension values via your previous bullet point.

But the use of semantic relationships such as skos:narrower doesn't imply that the so related concepts are part of the same concept scheme. So, if A inScheme S and B narrower A, then B isn't necessarily in S, and therefore isn't necessarily an allowed dimension value.

See http://www.w3.org/TR/skos-reference/#L2577

It is a mistake to think of skos:narrower as conferring membership in a concept scheme. That's what skos:inScheme is for.

> * 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)

Yes. Option number three.

> * Use qb:codeList with skos:Collection and define concepts via skos:member (from skos:Collection)

Yes. Option number four.

> * 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.

No.

1. To link a skos:ConceptScheme to its xkos:ClassificationLevels, use xkos:levels, not skos:inScheme. (That's how XKOS is supposed to be used, although using skos:inScheme here wouldn't be unreasonable as such.)

2. Nevertheless, skos:narrower doesn't imply being in the same scheme. You sill need to enumerate the actual concepts in the concept scheme via skos:inScheme. So, use option number two above.

(Perhaps membership in a classification level of a concept scheme should imply being in the concept scheme. More formally, { ?scheme xkos:levels/rdf:rest+/rdf:first/skos:member ?concept } should perhaps imply { ?concept skos:inScheme ?scheme }. But that would be something that the XKOS people would need to assert.)

> * 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.

I don't think so.

I don't think that nesting multiple xkos:ClassificationLevels via skos:member is an intended use of XKOS.

You can use qb:codeList with skos:Collection (or with a subclass of skos:Collection such as xkos:ClassificationLevel) if you want to indicate that only a certain named subset of concepts (e.g., only a particular level of the classification) are allowed as dimension values in the cube.

Best,
Richard


> 
> 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 Monday, 11 March 2013 18:59:53 UTC