Hello Paula,
apologies for the delay - your message arrived during the holiday season
and was then miscategorized.
There is indeed a bug in Tagger in that it only allows you to select
properties that have skos:Concept as their (direct) rdfs:range. I have
fixed this bug for the next release (5.3), and from then on people will
be able to also select properties that have a sub-property of
skos:Concept as range.
Meanwhile, you would need to do a manual work-around:
0) Make sure that the server enables SPARQL updates (in the Server
configuration parameters page)
1) Open the SPARQL endpoint page at
2) Execute the following update, here for the example of
tagged_paintings and a testProp property:
INSERT {
GRAPH <urn:x-evn-master:tagged_paintings> {
<urn:x-evn-master:tagged_paintings>
<http://evn.topbraidlive.org/tagger#tagProperty>
<http://example.org/taggerProps#testProp>
}
}
WHERE {
}
This query is the backdoor of telling your Tagger vocabulary which
properties to offer in the drop down box for tagging.
HTH
Holger
On 31/12/2016 2:17, Paula Markes wrote:
Hello,
I’ve been trying out the auto-classifier in tagger and have a question.
I use multiple tagging properties and each one should only have it's triple
object assigned from a specific part of the taxonomy tree. The taxonomies are
SKOS based, but they have subclasses of skos:Concept which are used as types
for instances in different taxonomy trees. What I would really like to do is
assign specific classes as the range to a tagging property. But if the tagging
property range is not skos:Concept, I cannot complete Step 2 of building thee
tagset because the properties do not show up in the “Default Tag Property” drop
down list box or in the “Tag Properties” check box.
Is there some way this can be updated to allow the use of a specific range for
the tagging property and not only skos:Concept?
At this time, the only way I can see as a work around for this to work with the
auto-classifier is to actually create a tagset for each individual tagging
property, and make sure the “Content Vocabulary” in Step 1 only has the
specific tree or trees that have the appropriate terms for the objects of the
tagging properties. And as we normally work with multiple tagging properties,
this would mean designing the Tagsets around the properties versus around the
content collections. And because there was a need to have specific collections
of information in separate content graphs, doing this type of separate by
tagging property could really multiple the number of tagsets in use.
Does this makes sense? Can you share your thoughts on this?
-Paula
--
You received this message because you are subscribed to the Google Group "TopBraid
Suite Users", the topics of which include the TopBraid Suite family of products and
its base technologies such as SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
