Jeen,
I took a closer look at our code base and found that Gokhan had
already implemented a SPARQL function for that purpose - it just
wasn't in the smf ontology yet and so I missed it (I have added it
now). With this you can generate rdfs:labels (with any language tag)
and assign it to newly created instances. Import spin.owl and then add
the following CONSTRUCT query to owl:Thing using spin:constructor:
CONSTRUCT {
?this rdfs:label ?label .
}
WHERE {
FILTER isIRI(?this) .
LET (?str := smf:generateLabel(?this, "{name}")) .
LET (?label := smf:setLanguage(?str, "nl")) .
}
Whenever you create a new instance with the create instance dialog,
the system will run this constructor. Note the smf:generateLabel
function, which may not auto-complete in your version, but it's there.
For example, for the resource MyInstance, it will return "My
instance". Attach a language tag using smf:setLanguage and you're done.
If you prefer not to use SPIN, you can use a query like the above in
the SPARQL view and assert or infer the results. For example, you
could check whether a resource does not have a label yet, and then
construct one.
I will also look at improving the create dialog to allow language tags
as suggested before.
Holger
On Sep 17, 2009, at 8:18 AM, Holger Knublauch wrote:
>
> Hi Jeen,
>
> yes that would make sense. I have no easy immediate solution for you.
> My first attempt was to try to use SPIN constructors for that, in
> which case you could derive the new label from the local name.
> Unfortunately, I don't think we have a built-in function to make this
> string transformation, e.g. so that "hasCustomer" becomes "has
> customer". I will try to add this for the next release. Meanwhile, you
> could theoretically implement this function yourself, using JavaScript
> and SPINx. The problem here would be that such SPIN constructors would
> need to be stored in the model, and therefore would make it difficult
> to set up a system in which international co-workers use different
> default languages.
>
> A more convenient approach would be if the string templates in the
> create dialogs would indeed allow something like {...@en} as you suggest,
> and this could be added. Or another mechanism would be to have a
> global default setting so that all new values for selected properties
> (rdfs:label and rdfs:comment for example) would get a language tag.
> This however looks like a more difficult change, because there are
> multiple places in which such literals are created.
>
> Holger
>
>
>
> On Sep 17, 2009, at 4:53 AM, Jeen wrote:
>
>>
>> Is it possible to have TBC automatically add a particular language
>> tag
>> to a literal value in an annotations template?
>>
>> What I want is to be able to create a new class, and automatically
>> generate the rdfs:label (using the annotations template), _but_ I
>> would like to have this value annotated with the @en language tag.
>>
>> I thought at first this might do the trick:
>>
>> {name} {...@en}
>>
>> Unfortunately this does not work. I've tried various ways to escape
>> the accolades but to no avail.
>>
>>
>>
>>
>>
>>>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TopBraid Composer Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---
