I can only speak for our product named Bmd. In our product you can search and view regardless of whether you have 3 properties or one additional object that has the three values. We do not, however, support viewing of annotations without some customization although we do use annotations for a number of purposes.
Our product can either be used integrated for tagging files in the XDocs repository where you have lots of UI or as a stand alone OWL2 repository which would require some customizations.
From: TaxoCoP@yahoogroups.com [mailto:TaxoCoP@yahoogroups.com] On Behalf Of Gabriel Tanase
Sent: October-30-13 1:48 AM
Subject: Re: [TaxoCoP] Converting Data to SKOS assistance
Indeed, that is the intended meaning.
IMHO it might have been more obvious if the source database had been normalized e.g. in three tables: Concept(Code, ...) , ConceptAttribute(Code, Name, Value) and
ConceptAttributeSource(Code, Name, Value).
Maybe Nathan does not have control over how data is made available in the database.
My follow-up question is: since the implementation would be based on customizing the underlying OWL ontology, rather than on plain annotations, how simply would tools that handle annotations out-of-the-box be able to show values from the added property as annotations, or in a manner very similar to how they display annotations?
Perhaps this is not possible at all, and - hopefully - perhaps this does not matter for the end-users / downstream systems' perspective.
All they might need is to access the annotative data in a meaningful manner.
Doing that, you could assign three Q10 values, three Q12 values, and three Q47 values to concept C113266, but I believe he wants to record the fact that first Q10, Q12, and Q47 values go together (as Annotation set 123), the second Q10, Q12, and Q47 values go together (as Annotation set 456), etc., which would require an extra data structure.
On Tue, Oct 29, 2013 at 5:46 PM, Jim Tivy <jimt@...
Why not just add a few more properties to skos:Concept that contain your extra data.
SKOS has no way to group annotations together into packages with their own identity (e.g. http://some/path/123
) separate from the identity of Concepts and, in SKOS-XL, from Labels. However, because SKOS is an OWL ontology it's extensible, so you could declare an xyz:Annotation class in your own namespace that has the properties you need. Then, to attach each annotation package to a Concept, I would declare a new property, perhaps as a subproperty of skos:notation, that has skos:Concept as its domain (to show that it's a property of concepts) and xyz:Annotation as its range to show that that's where the
values come from.
The flexibility of SKOS-XL is great in theory but makes it more difficult to implement an easy-to-use tool for manipulating the data, and if you make the model even more complex by adding a customized xyz:Annotation class, then specialized SKOS tools will not be able to handle something like this out of the box, so you'd have to use a more generalized RDF tool like TopBraid Composer or Protege.
(Full disclosure: I work for TopQuadrant, which makes the SKOS-based EVN vocabulary manager EVN as well as TopBraid Composer.)
On Tue, Oct 29, 2013 at 4:07 PM, Nathan Wilson <wilsns01@...
I am working on a project which involves converting data from a database into a SKOS-XL format and I have an issue involving annotative data.
For each term there are three pieces of annotative data:
3. Source_Local_Code (Q12)
When I convert the data to SKOS I get the following output:
In the data base there is an ID which is used to group annotative data together:
ID Concept Code Attribute Code Attribute Name Attribute Value Annotation Code Annotation Name Annotation Value
123 C113266 P90 SYN
Black (Not of Hispanic Origin) Q10 Source PROTRAK-CC
123 C113266 P90 SYN Black (Not of Hispanic Origin) Q12 Source_Local_Code Black (Not of Hispanic Origin)
123 C113266 P90 SYN Black (Not of Hispanic Origin) Q47 Source_Domain Race and Ethnicity Combined
456 C113266 P90 SYN Black (Not of Hispanic Origin) Q10 Source NIAAA
456 C113266 P90 SYN Black (Not of Hispanic
Origin) Q12 Source_Local_Code B
456 C113266 P90 SYN Black (Not of Hispanic Origin) Q47 Source_Domain Race and Ethnicity Combined
789 C113266 P90 SYN Black (Not of Hispanic Origin) Q10 Source MIS-CC
789 C113266 P90 SYN Black (Not of Hispanic Origin) Q12 Source_Local_Code B
789 C113266 P90 SYN Black (Not of Hispanic Origin) Q47 Source_Domain
Race and Ethnicity Combined
Is there a way to include this grouping in SKOS-XL or is this grouping unique to the database and not implementable in the vocabulary?