Re: how to: ordered collection of a Concept

Hi Vladimir, all,

A design note on SKOS: skos:Collection and skos:OrderedCollection are the way they are because of the need to remain "simple", as SKOS' mandate was.

Ordering is not so common (not saying that it's super-rare, but it's certainly not the majority of cases). Most applications (except the very applications that are dedicated to building or viewing 'ordered schemes') that we've seen don't really use them. And in fact I believe it would be a burden for many data consumers if accessing AAT's hierarchy was hampered by having to handle order.

The current skos:(Order)Collection construct has the benefit of not standing in the path of consuming data. It is really an extra layer on top of the simple hierarchy. People interested in the order can exploit it if they want. Those who don't care will very safely ignore it.

Finally, order is also a characteristics that resists update very badly, so it's not bad if it remains outside of a framework that's supposed to stay "simple".

Cheers,

Antoine



> On 2013-11-10 20:19, Vladimir Alexiev wrote:
>> AAT has notations, these are the primary keys of concepts, e.g. "300019279" is "Iron Age".
>> Using notations for ordering is NOT a good idea, because there's no guarantee notations will be in any reasonable order.
>> AAT has a separate field in the database. We will map it to a custom field (gvp:sortOrder),
>> but the subject of this discussion is how to map it in a standard way.
> The AAT number that you refer to above is a concept identifier, not a notation. The ISO model provides for both of these, the distinction being that generally the identifier is an arbitrary number or symbol, permanently associated with a concept even though changes in scope and labels. A notation normally has some inherent significance, for example indicating the place of the concept in a hierarchy and/or being in a form which can be sorted to arrange concepts in the desired order.
>> The standard way is the rdf:List in skos:OrderedCollection (and same for an iso:ThesaurusArray that is ordered).
>>
>>> - Must the (possibly multiple) ordering be represented in generic RDF constructs (rdf:List).
>>> - Must a modeling schema detail the (possibly multiple) thesaurus orderings in dedicated RDF/S or OWL constructs.
>> Creating such a list is a finickly job, and I'm not sure whether there exists a TMS consuming such lists, but the SKOS standard is clear: we must use rdf:List.
>> Each skos:OrderedCollection (or iso:ThesaurusArray that is ordered) may impose its own list on its members.
>> In the case of the Getty thesauri, the list of members may vary in the poly-hierarchy, but the order between them will be always the same. In other thesauri, it may be different.
> I don't know any examples, but in any well-structured thesaurus the list of narrower concepts under any concept should be the same wherever that parent concept occurs in a polyhierarchy. Perhaps the AAT is just choosing to display only some of the narrower terms in some occurrences, though the full list should still apply.
>> My question is how to order the children of a *concept*.
>> Here's an AAT example: Iron Age is a concept that has ordered children.
>> http://www.getty.edu/vow/AATHierarchy?find=300198841&logic=AND&note=&subjectid=300019279
>>
>> My question is how to relate the skos:OrderedCollection=iso:ThesaurusArray to this parent concept.
>>
>> I propose iso:equivalentArray for this. It's not an ideal solution, since we'd still need to make an Array node and give it labels.
> The example you give is
>
>       Iron Age
>                  Early Iron Age
>                  Middle Iron Age
>                  Late Iron Age
>
> The latter three concepts are just a standard array, as shown in the ISO model, with the SuperOrdinateConcept "Iron Age" and the attribute "ordered = true". The ISO model does not specify how the ordering is to be maintained. It might just be that the order in which the concepts are presented should be maintained and that they should not be sorted in any other order, such as alphabetically. In some systems it may be necessary to use a sort key, but that is considered an issue for application software.
>
> The above array could have had a node label, as shown here, but this is optional in the ISO model:
>
>       Iron Age
>                  <Iron Age periods by time>
>                  Early Iron Age
>                  Middle Iron Age
>                  Late Iron Age
>
> There does not seem to be any need to introduce something new such as the "iso:equivalentArray" you suggest.
>> Unfortunately both SKOS and ISO are adamant that Concept is disjoint from Collection, Array and Group.
> True. Arrays and ConceptGroups each contain one or more Concepts. I assume that this makes them disjoint from Concepts. I can't comment on "Collections", as this is a SKOS idea that does not occur in the ISO model.
>> But neither has thought that Concept shares a lot of features with Collection, Array and Group:
>> they all have labels, they can hold children, those can be ordered.
>> This causes spurious differences in representation, that we should strive to eliminate as much as possible.
> How do you suggest that the representations could be made more similar, while preserving the distinctions between these disjoint elements.?
>> An aside:
>> - IMHO, skos:Collection and skos:OrderedCollection are defunct since you can't place them under anything.
>> - so I welcome the addition of iso:ThesaurusArray
>> - on the other hand, iso:ConceptGroup can't be ordered and you can't place an Array under a Group, so we won't be using Group in representing the Getty thesauri
> Concepts within a ConceptGroup can be ordered, because they can have a notation which can act as a sort key. When a concept is added to a ConceptGroup, it can still retain its children, i.e. any array of narrower terms which may be subordinated to it, and these can be ordered. You probably don't need ConceptGroups to represent the Getty thesaurus, though, as it does not have microthesauri, or subject groups which draw concepts from several facets independently of the hierarchical structure.
>
>> Your advise and feedback is most welcome!
>> Cheers! Vladimir
> I hope that this helps.
>
> Leonard
>

Received on Monday, 11 November 2013 20:39:02 UTC