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

Dave, thanks, for taking the time for looking into this issue,

> I don't know enough about xkos to know if your modelling is normal.
> But
> looking at the xkos vocabulary then isn't the xkos:levels property
> intended to link a skos:ConceptScheme to the
> xkos:ClassificationLevels?
True, but given the xkos:ClassificationLevels have an xkos:depth, I do not see the reason for going through the hassle of creating and querying rdf:Lists.

> surely that must be in *addition* to skos:inScheme links for the
> skos:Concepts within the levels, not instead of them. It seems to me
> that you could take your representation and run a closure rule over
> it
> to identify all the concepts which are in the scheme directly or
> indirectly via your levels. This closure is then what you would use
> in
> cube validation.
That is fine for me. 

> This would allow the last of the options in your list to be validated
> and so give you at least one clear way of handling levels.
OK.

> Given this change, and the discussion on skos:inScheme are you
> content
> to continue with Last Call?
Since both above ways to reuse xkos can be extended to validate as cubes, I am content.

Best,

Benedikt

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

On 08/03/13 12:29, Benedikt Kaempgen wrote:
> 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.

Hmm. We only have a couple of hours left in which to work through this
... but here goes ...

I don't know enough about xkos to know if your modelling is normal. But
looking at the xkos vocabulary then isn't the xkos:levels property
intended to link a skos:ConceptScheme to the xkos:ClassificationLevels?

In my view every skos:Concept which is in a skos:ConceptScheme can be
linked to it by skos:inScheme. I know that the domain of skos:inScheme
is open so your use of putting the xkos:ClassificationLevels as
skos:inScheme the skos:ConceptScheme is legal from a SKOS viewpoint. But
surely that must be in *addition* to skos:inScheme links for the
skos:Concepts within the levels, not instead of them. It seems to me
that you could take your representation and run a closure rule over it
to identify all the concepts which are in the scheme directly or
indirectly via your levels. This closure is then what you would use in
cube validation.

However, you are quite right that skos:Collections can nest so the
correct version of rule 19a should allow for chains of skos:member:

ASK {
    ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
    ?dim a qb:DimensionProperty ;
         qb:codeList ?list .
    ?list a skos:Collection .
    ?obs ?dim ?v .
    FILTER NOT EXISTS { ?list skos:member+ ?v }
}

This would allow the last of the options in your list to be validated
and so give you at least one clear way of handling levels.

I will make this change.

Given this change, and the discussion on skos:inScheme are you content
to continue with Last Call?

Cheers,
Dave


> ________________________________________
> 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 14:20:00 UTC