spaces in api:label values cause labels to not be used

[Stephan Zednik]

I used the api:label property to define labels for classes and properties at occur in my linked data.

I noticed the api:label value is not used if it's values contains a space.

Is this a known restriction (as opposed to say a bug in my configuration) and if so is there a reason for this restriction?

Here is some snippets from my spec in case this is the result of my config not being setup properly.

spec:api a api:API;
# ... labels and sparql endpoint
api:defaultViewer api:labelledDescribeViewer;
api:defaultFormatter spec:htmlFormatter;
api:viewer
api:describeViewer,
api:labelledDescribeViewer;
api:endpoint
# my endpoints

spec:htmlFormatter a api:XsltFormatter
; api:name "html"
; api:mimeType "text/html; charset=utf-8"
; api:stylesheet "lda-assets/xslt/gcis.xsl".

# my endpoints
# ...

# now define properties and set api:label on them

# this label value is used
gcis:hasConveningLeadAuthor
a rdf:Property;
api:label "convening_lead_author";
.

# this label value would not be used
#gcis:hasConveningLeadAuthor
# a rdf:Property;
# api:label "convening lead author";
# .

Thanks,
Stephan

[Keith Alexander]

On Fri, Nov 16, 2012 at 11:17 PM, Stephan Zednik <zed...@rpi.edu> wrote:

I used the api:label property to define labels for classes and properties at occur in my linked data.

I noticed the api:label value is not used if it's values contains a space.

Is this a known restriction (as opposed to say a bug in my configuration) and if so is there a reason for this restriction?

Yes; api:labels are supposed to always be valid  JSON property names I think ... embarrassingly api:label doesn't seem to be in the defined vocab ... 

but http://code.google.com/p/linked-data-api/wiki/API_Property_Paths has a regex of characters you can use in a property.

[Stephan Zednik]

On Nov 16, 2012, at 4:29 PM, Keith Alexander <keithal...@keithalexander.co.uk> wrote:

On Fri, Nov 16, 2012 at 11:17 PM, Stephan Zednik <zed...@rpi.edu> wrote:

I used the api:label property to define labels for classes and properties at occur in my linked data.

I noticed the api:label value is not used if it's values contains a space.

Is this a known restriction (as opposed to say a bug in my configuration) and if so is there a reason for this restriction?

Yes; api:labels are supposed to always be valid  JSON property names I think ... embarrassingly api:label doesn't seem to be in the defined vocab ... 

but http://code.google.com/p/linked-data-api/wiki/API_Property_Paths has a regex of characters you can use in a property.

I thought 'valid; JSON property names were required to be strings and therefore support white spaces.

http://stackoverflow.com/questions/5716792/json-fieldnames-spaces

http://stackoverflow.com/questions/380855/json-syntax-for-property-names

--Stephan

[chris dollin]

On 19 November 2012 16:49, Stephan Zednik <lokip...@gmail.com> wrote:

> I thought 'valid; JSON property names were required to be strings and
> therefore support white spaces.

My recollection is that we specified that a LDA shortname had to
be legal as a Javascript variable name, so that JS applications that
called through tot he API could refer to any of the shortnamed members
of a fetched JSON structure using plain field names.

Chris

--
Chris "allusive" Dollin

[Keith Alexander]

yep. sorry, i was imprecise; i meant javascript property names that can be used with dot notation (ie, javascript identifiers).
In any case, the spec does give that regex, and it appears that Chris and I interpreted it the same way in Elda and Puelia respectively.
 

[Stephan Zednik]

Ah, OK.

The spec regex makes it clear, but the relevance of the regex was not clear during my initial reading of the pages at http://code.google.com/p/linked-data-api/wiki/Specification.  

Also, as was mentioned api:label is not defined in the vocab page (http://code.google.com/p/linked-data-api/wiki/API_Vocabulary), but does show up in the examples.

I like the idea of api:labelledDescribeViewer but in usage it is being very hit or miss with existing labels since many of the labels I am working with have spaces in them.  It took me a while to figure out that spaces were the cause since the restriction was non-intuitive to me.  

I think I will use a camelCase convention in api:label values I add to override the rdfs:label values that have spaces...

I would prefer that the value of a 'valid' api:label / rdfs:label for the labelledDescribeViewer be any valid xsd:string as it would allow me to use existing labels with confidence they will be 'valid', but I understand the compromise due to design.

--Stephan

[chris dollin]

On 19 November 2012 17:12, Stephan Zednik <lokip...@gmail.com> wrote:

>
> I like the idea of api:labelledDescribeViewer but in usage it is being very
> hit or miss with existing labels since many of the labels I am working with
> have spaces in them. It took me a while to figure out that spaces were the
> cause since the restriction was non-intuitive to me.

I don't understand. The labels used in the data returned by a
labelled-describe viewer have nothing to do with shortnames.

Could you give us a specific example?

[Stephan Zednik]

On Nov 20, 2012, at 1:37 AM, chris dollin <ehog....@googlemail.com> wrote:

> On 19 November 2012 17:12, Stephan Zednik <lokip...@gmail.com> wrote:
>
>>
>> I like the idea of api:labelledDescribeViewer but in usage it is being very
>> hit or miss with existing labels since many of the labels I am working with
>> have spaces in them. It took me a while to figure out that spaces were the
>> cause since the restriction was non-intuitive to me.
>
> I don't understand. The labels used in the data returned by a
> labelled-describe viewer have nothing to do with shortnames.

I might have wrongly assumed you needed to specify a labelledDescribeViewer to leverage the api:label values. The connections are not clearly documented so I am making assumptions based on the examples.

Whether a labelled viewer is needed or not, I like the idea of being able to leverage labels in the viewers. Unfortunately, a great deal of the RDF I am using has spaces in property & class labels.

--Stephan

[Stephan Zednik]

Interesting. I just tested and discovered that if you use camelCase labels the label value is translated to lowercase with spaces. I am using a slightly tweaked version of result.xsl for my HTML viewer. This is great because it gives me the presentation in HTML I want.

gcis:hasConveningLeadAuthor
a rdf:Property;

api:label "conveningLeadAuthor";

leads to "convening lead author" in the HTML presentation.

This resolves my need. Based on the HTML source it appears the XSLT is performing the translation.

Thanks,
--Stephan

[Stuart Williams]

Hello Stephan,

api:label is purely used for associating a shortname with a URI (class, property
or instance) so that you can create filters and viewers (property-chain viewers).

The labelledDescribeViewer, by default, seeks to obtain rdfs:labels for every
subject/object (inc closures over b-nodes) mentioned in a response.

There should be no problem with spaces in your rdfs:labels.

If you want to pick different property for the labelledDescribeViewer to
retrieve (eg. skos:prefLabel) there is a way to configure elda to do so.

api:labels are part of the api configuration whereas you'd normally expect to
use rdfs:label, skos:prefLabel and/or skos:altLabel in the data you are serving.

HTH

Stuart
--

--
Epimorphics Ltd www.epimorphics.com
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

[Stephan Zednik]

OK.

I changed all my uses of api:label to rdfs:label and set my default viewer to labelledDescribeViewer.

My spec now defines a property with label as such (should also be defined with this label in the sparql endpoint).

gcis:hasChiefEditor

a rdf:Property;

rdfs:label "chief editor";

.

The property is showing up as 

<tr class="gcis_hasChiefEditor">

<th class="label"><a href="http://data.globalchange.gov/gcis.owl#hasChiefEditor">gcis_has chief editor</a></th><td class="value"><a href="http://data.globalchange.gov/person/Thomas_R_K">Thomas_R_K</a></td><td class="filter"></td>

</tr>

In the HTML generated by my slightly tweaked result.xsl viewer.

The JSON looks like

{"chief editor" : "http://data.globalchange.gov/person/Thomas_R_K"}

so the JSON property name looks like it is using the rdfs:label value.

Perhaps my issue is really just with my XsltFormatter?

--Stephan

[Stuart Williams]

Hello Stephan,

On 20/11/2012 18:20, Stephan Zednik wrote:
> OK.
>
> I changed all my uses of api:label to rdfs:label and set my default viewer to labelledDescribeViewer.

Hmmm that's not what I was suggesting that you did in your config - however I
think you're saying that worked for you, plus some tinkering with the XSL (which
in general I'd advise against).

I suspect that the source of what may have been some confusion (recall, you were
asking about labelledDescribeViewer at the start of this thread) is the question
of when 'labels' presented in the HTML rendered output (<a href="someUri">label
text</a>) come from.

For RDF statement subjects and objects - they come from rdfs:label in the data -
at least that's what the labelledDescribeViewer 'attracts' into the result
graph, though it can be configured for a different property. Absent an
rdfs:label the XSL stylesheet will applies some heuristics (I don't recall the
order) that roughly look for:

1) other labelling properties (skos:prefLabel and/or skos:altLabel - in the
result graph - the XSL engine doesn't look in the datastore, that query has
already happened and the labelledDescribeViewer - if that's what you used - has
already had its effect).
2) the localname of the property URI *if* it meets the syntactic constraints
required of being a LDA shortname.

For RDF statement properties, the labeling comes from the api configuration
itself, specifically api:label properties used to establish shortnames.

> My spec now defines a property with label as such (should also be defined with this label in the sparql endpoint).
>
> gcis:hasChiefEditor
> a rdf:Property;
> rdfs:label "chief editor";
> .

That won't give you control of a shortname - you need to use api:label for that.

>
> The property is showing up as
>
> <tr class="gcis_hasChiefEditor">
> <th class="label"><a href="http://data.globalchange.gov/gcis.owl#hasChiefEditor">gcis_has chief editor</a></th><td class="value"><a href="http://data.globalchange.gov/person/Thomas_R_K">Thomas_R_K</a></td><td class="filter"></td>
> </tr>

Ah... that's because absent a shortname elda has *made one up* using the
property URIs local name and a matching prefix (gcis in this case) visible in
the api configuration.

> In the HTML generated by my slightly tweaked result.xsl viewer.
>
> The JSON looks like
> {"chief editor" : "http://data.globalchange.gov/person/Thomas_R_K"}
> so the JSON property name looks like it is using the rdfs:label value.
>
> Perhaps my issue is really just with my XsltFormatter?

Hard to say as I for one of lost the plot on what your issue actually is. I'm
surprise that you should need to 'tweak' result.xsl over and above some cosmetic
changes to change page banners and the like.

>
> --Stephan

Stuart
--

[Stephan Zednik]

On Nov 21, 2012, at 5:28 AM, Stuart Williams <s...@epimorphics.com> wrote:

Hello Stephan,

On 20/11/2012 18:20, Stephan Zednik wrote:

OK.

I changed all my uses of api:label to rdfs:label and set my default viewer to labelledDescribeViewer.

Hmmm that's not what I was suggesting that you did in your config - however I think you're saying that worked for you, plus some tinkering with the XSL (which in general I'd advise against).

Changing banners for the time being, but I will later have to change the mapping code since I use geosparql to encode geospatial information.

I suspect that the source of what may have been some confusion (recall, you were asking about labelledDescribeViewer at the start of this thread) is the question of when 'labels' presented in the HTML rendered output (<a href="someUri">label text</a>) come from.

I was asking about how to get nicely formatted labels, which contained spaces, in the HTML presentation of the labels.  My original HTML contained label names which had the prefix with and underscore as part of the label.

The HTML representation looked like the following and I was looking for ways to clean it up.

[Stuart Williams]

Hello Stephan

I've said this in the previous message, but you may have missed it.... so let me
try again without embedding it in the trail that's gone before.

In the HTML renderings:

a) URI nodes in subject or object positions are labelled with:
i) rdfs:label if present in the response graph
ii) skos:prefLabel if present in response graph
i) and ii) precidence may be the reverse of this.
iii) Otherwise property short name
This is behaviour induced by the XSL stylesheet

b) URI nodes in the property position of a statement are labelled with
a rending of their short name (the XSL an uncamel casing approach).

c) Short names for properties come from:
i) api:label statements in the API configuration (if present)
ii) URI localname and prefix if the local name is admissable as a shortname
and (since elda versions after 1.2.13) the prefix is defined in the API
config file.
iii) Otherwise, (since elda version after 1.2.13) a %-encoded mangling of the
property URI so that property filtering and projection can still be
accomplished
(the XSL embeds many such links - which would otherwise 404). If you
encounter
these, your minimal response its likely to add the prefix defn to the
API config,
and more like you'll want to take full control of the shortname.

Key point is that the labelling source for URI in property positions is
*different* from labelling source for URI in subject and object positions of a
response.

Stuart
--
[Feeling that there is no more light to shed]

> I looked at the sample specs to try to understand why the HTML from the sample APIs looked nicer.
>
> I started defining the properties in the spec file and attaching api:label statements to them which resolved the issue of the undesired prefix in the label name, but I then ran into an issue of not being able to leverage spaces in the label value. Based on your feedback, I changed the api:label statements to be rdfs:label statements, but I still get the same issue with spaces in the label.
>
> For example if I use the following in my spec then I see "head honcho" as the property name in the HTML presentation, so the label value is clearly being leveraged.

>
> gcis:hasChiefEditor
> a rdf:Property;

> rdfs:label "headHoncho";
> .
>
> If I use the following, I get "gcis_has chief editor" in the HTML, so the label is being ignored and the label name in the HTML is generated based on the property URI.

>
> gcis:hasChiefEditor
> a rdf:Property;

> rdfs:label "head honcho";
> .
>
> This issue confused me for a while because I did not know what was going on. It appears that if there is a space in the rdfs:label value the XSL stylesheet is applying heuristics to determine the label name from the property URI, whereas if there is no space in the rdfs:label value it is applying a different set of heuristics to the label value to convert camelCase to lowercase with spaces.
>
> I admit I was guessing as to whether labelledDescribeViewer had a connection to any of this. The only documentation I found on labelledDescribeViewer was
>
> api:labelledDescribeViewer is named "all" and returns a graph that is whatever is returned by a DESCRIBE query for the item on the SPARQL endpoint, supplemented by rdfs:label properties for all referenced resources. Again, the precise details of what's returned will depend on the SPARQL endpoint.
>
> from http://code.google.com/p/linked-data-api/wiki/API_Viewing_Resources
>
> I was not sure if this meant property labels would be picked up as well, but on reflection I supposed they would not.

>
>>
>> For RDF statement subjects and objects - they come from rdfs:label in the data - at least that's what the labelledDescribeViewer 'attracts' into the result graph, though it can be configured for a different property.
>

> Do you have a link to the documentation on this? I have skos and foaf data in my repository so I would like to pull rdfs:label, dct:title, foaf:name, and skos:prefLabel values if available.

>
>> Absent an rdfs:label the XSL stylesheet will applies some heuristics (I don't recall the order) that roughly look for:
>
>>
>> 1) other labelling properties (skos:prefLabel and/or skos:altLabel - in the result graph - the XSL engine doesn't look in the datastore, that query has already happened and the labelledDescribeViewer - if that's what you used - has already had its effect).
>> 2) the localname of the property URI *if* it meets the syntactic constraints required of being a LDA shortname.
>>
>> For RDF statement properties, the labeling comes from the api configuration itself, specifically api:label properties used to establish shortnames.
>

> Ah, this was not intuitive to me. Is it in the documentation somewhere?
>
> From what you are saying I should be using api:label instead of rdfs:label on the properties defined in my spec file and I deduce I need to use camelCase when I want a multi-word label.

>
>>
>>> My spec now defines a property with label as such (should also be defined with this label in the sparql endpoint).
>>>
>>> gcis:hasChiefEditor
>>> a rdf:Property;
>>> rdfs:label "chief editor";
>>> .
>>
>> That won't give you control of a shortname - you need to use api:label for that.
>

> ...and yet it seems to work...

>
>>>
>>> The property is showing up as
>>>
>>> <tr class="gcis_hasChiefEditor">
>>> <th class="label"><a href="http://data.globalchange.gov/gcis.owl#hasChiefEditor">gcis_has chief editor</a></th><td class="value"><a href="http://data.globalchange.gov/person/Thomas_R_K">Thomas_R_K</a></td><td class="filter"></td>
>>> </tr>
>>
>> Ah... that's because absent a shortname elda has *made one up* using the property URIs local name and a matching prefix (gcis in this case) visible in the api configuration.
>>
>>> In the HTML generated by my slightly tweaked result.xsl viewer.
>>>
>>> The JSON looks like
>>> {"chief editor" : "http://data.globalchange.gov/person/Thomas_R_K"}
>>> so the JSON property name looks like it is using the rdfs:label value.
>>>
>>> Perhaps my issue is really just with my XsltFormatter?
>>
>> Hard to say as I for one of lost the plot on what your issue actually is. I'm surprise that you should need to 'tweak' result.xsl over and above some cosmetic changes to change page banners and the like.
>

> Currently cosmetic, but as mentioned above I use geosparql to encode geospatial information so I will have to make changes to the mapping JS scripts.
>
> --Stephan
>
>>
>>>
>>> --Stephan
>>
>> Stuart
>> --

>>
>>>
>>> On Nov 20, 2012, at 11:06 AM, Stuart Williams <s...@epimorphics.com> wrote:
>>>
>>>> Hello Stephan,
>>>>

> I looked at the sample specs to try to understand why the HTML from the sample
> APIs looked nicer.
>
> I started defining the properties in the spec file and attaching api:label
> statements to them which resolved the issue of the undesired prefix in the label
> name, but I then ran into an issue of not being able to leverage spaces in the
> label value. Based on your feedback, I changed the api:label statements to be
> rdfs:label statements, but I still get the same issue with spaces in the label.
>
> For example if I use the following in my spec then I see "head honcho" as the
> property name in the HTML presentation, so the label value is clearly being
> leveraged.

>
> gcis:hasChiefEditor
> a rdf:Property;

> rdfs:label "headHoncho";
> .
>
> If I use the following, I get "gcis_has chief editor" in the HTML, so the label
> is being ignored and the label name in the HTML is generated based on the
> property URI.

>
> gcis:hasChiefEditor
> a rdf:Property;

> rdfs:label "head honcho";
> .
>
> This issue confused me for a while because I did not know what was going on. It
> appears that if there is a space in the rdfs:label value the XSL stylesheet is
> applying heuristics to determine the label name from the property URI, whereas
> if there is no space in the rdfs:label value it is applying a different set of
> heuristics to the label value to convert camelCase to lowercase with spaces.
>
> I admit I was guessing as to whether labelledDescribeViewer had a connection to
> any of this. The only documentation I found on labelledDescribeViewer was
>
> api:labelledDescribeViewer is named "all" and returns a graph that is whatever
> is returned by a DESCRIBE query for the item on the SPARQL endpoint,
> supplemented by rdfs:label properties for all referenced resources. Again, the
> precise details of what's returned will depend on the SPARQL endpoint.
>
> from http://code.google.com/p/linked-data-api/wiki/API_Viewing_Resources
>
> I was not sure if this meant property labels would be picked up as well, but on
> reflection I supposed they would not.

>
>>
>> For RDF statement subjects and objects - they come from rdfs:label in the data
>> - at least that's what the labelledDescribeViewer 'attracts' into the result
>> graph, though it can be configured for a different property.
>

> Do you have a link to the documentation on this? I have skos and foaf data in
> my repository so I would like to pull rdfs:label, dct:title, foaf:name, and
> skos:prefLabel values if available.

>
>> Absent an rdfs:label the XSL stylesheet will applies some heuristics (I don't
>> recall the order) that roughly look for:
>
>>
>> 1) other labelling properties (skos:prefLabel and/or skos:altLabel - in the
>> result graph - the XSL engine doesn't look in the datastore, that query has
>> already happened and the labelledDescribeViewer - if that's what you used -
>> has already had its effect).
>> 2) the localname of the property URI *if* it meets the syntactic constraints
>> required of being a LDA shortname.
>>
>> For RDF statement properties, the labeling comes from the api configuration
>> itself, specifically api:label properties used to establish shortnames.
>

> Ah, this was not intuitive to me. Is it in the documentation somewhere?
>
> From what you are saying I should be using api:label instead of rdfs:label on
> the properties defined in my spec file and I deduce I need to use camelCase when
> I want a multi-word label.

>
>>
>>> My spec now defines a property with label as such (should also be defined
>>> with this label in the sparql endpoint).
>>>
>>> gcis:hasChiefEditor
>>> a rdf:Property;
>>> rdfs:label "chief editor";
>>> .
>>
>> That won't give you control of a shortname - you need to use api:label for that.
>

> ...and yet it seems to work...

>
>>>
>>> The property is showing up as
>>>
>>> <tr class="gcis_hasChiefEditor">
>>> <th class="label"><a
>>> href="http://data.globalchange.gov/gcis.owl#hasChiefEditor">gcis_has chief
>>> editor</a></th><td class="value"><a
>>> href="http://data.globalchange.gov/person/Thomas_R_K">Thomas_R_K</a></td><td
>>> class="filter"></td>
>>> </tr>
>>
>> Ah... that's because absent a shortname elda has *made one up* using the
>> property URIs local name and a matching prefix (gcis in this case) visible in
>> the api configuration.
>>
>>> In the HTML generated by my slightly tweaked result.xsl viewer.
>>>
>>> The JSON looks like
>>> {"chief editor" : "http://data.globalchange.gov/person/Thomas_R_K"}
>>> so the JSON property name looks like it is using the rdfs:label value.
>>>
>>> Perhaps my issue is really just with my XsltFormatter?
>>
>> Hard to say as I for one of lost the plot on what your issue actually is. I'm
>> surprise that you should need to 'tweak' result.xsl over and above some
>> cosmetic changes to change page banners and the like.
>

> Currently cosmetic, but as mentioned above I use geosparql to encode geospatial
> information so I will have to make changes to the mapping JS scripts.
>
> --Stephan

>
>>
>>>
>>> --Stephan
>>
>> Stuart
>> --
>>
>>>
>>> On Nov 20, 2012, at 11:06 AM, Stuart Williams <s...@epimorphics.com

>>> <mailto:s...@epimorphics.com>> wrote:
>>>
>>>> Hello Stephan,
>>>>
>>>> api:label is purely used for associating a shortname with a URI (class,
>>>> property or instance) so that you can create filters and viewers
>>>> (property-chain viewers).
>>>>
>>>> The labelledDescribeViewer, by default, seeks to obtain rdfs:labels for
>>>> every subject/object (inc closures over b-nodes) mentioned in a response.
>>>>
>>>> There should be no problem with spaces in your rdfs:labels.
>>>>
>>>> If you want to pick different property for the labelledDescribeViewer to
>>>> retrieve (eg. skos:prefLabel) there is a way to configure elda to do so.
>>>>
>>>> api:labels are part of the api configuration whereas you'd normally expect
>>>> to use rdfs:label, skos:prefLabel and/or skos:altLabel in the data you are
>>>> serving.
>>>>
>>>> HTH
>>>>
>>>> Stuart
>>>> --
>>>> On 20/11/2012 17:46, Stephan Zednik wrote:
>>>>>
>>>>> On Nov 20, 2012, at 1:37 AM, chris dollin <ehog....@googlemail.com

>>>>> <mailto:ehog....@googlemail.com>> wrote:
>>>>>
>>>>>> On 19 November 2012 17:12, Stephan Zednik <lokip...@gmail.com

>>>>>> <mailto:lokip...@gmail.com>> wrote:
>>>>>>
>>>>>>>
>>>>>>> I like the idea of api:labelledDescribeViewer but in usage it is being very
>>>>>>> hit or miss with existing labels since many of the labels I am working with
>>>>>>> have spaces in them. It took me a while to figure out that spaces were the
>>>>>>> cause since the restriction was non-intuitive to me.
>>>>>>
>>>>>> I don't understand. The labels used in the data returned by a
>>>>>> labelled-describe viewer have nothing to do with shortnames.
>>>>>
>>>>> I might have wrongly assumed you needed to specify a labelledDescribeViewer
>>>>> to leverage the api:label values. The connections are not clearly
>>>>> documented so I am making assumptions based on the examples.
>>>>>
>>>>> Whether a labelled viewer is needed or not, I like the idea of being able
>>>>> to leverage labels in the viewers. Unfortunately, a great deal of the RDF
>>>>> I am using has spaces in property & class labels.
>>>>>
>>>>> --Stephan
>>>>>
>>>>>>
>>>>>> Could you give us a specific example?
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> --
>>>>>> Chris "allusive" Dollin
>>>>>
>>>>
>>>> --

>>>> Epimorphics Ltd www.epimorphics.com <http://www.epimorphics.com>

>>>> Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
>>>> Tel: 01275 399069
>>>>
>>>> Epimorphics Ltd. is a limited company registered in England (number 7016688)
>>>> Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20
>>>> 6PT, UK
>>>
>>>
>>
>> --

>> Epimorphics Ltd www.epimorphics.com <http://www.epimorphics.com>

[Augusto Herrmann]

Hi, Stuart!

We have the same problem as Stephan. We want to have nicely displayed labels for the properties in the HTML renderings. But, alas, from reading this thread it seems it is just not possible - we're stuck with shortnames only.

We especially needed to display nicely formatted labels for the properties in HTML because we need accented characters in our language (which are obviously not acceptable in shortnames). We wish we could just display the properties' labels instead of their shortnames.

For instance, in http://orcamento.dados.gov.br/doc/acao/4061

we want to display "código na Lei Orçamentária Anual", or at least "código LOA", instead of "codigo LOA" for the property, but it seems not to be possible under any configuration, given these rules you mentioned. Perhaps this should be changed?

BTW, here's the contents of our configuration file: http://dev.dados.gov.br/codigo/outros/orcamento-linked-data/files/6d14abb3ef0405371849a91c20732bb318935a20/specs/orcamento.ttl

Best regards,

Augusto Herrmann

[Stuart Williams]

Hello Augusto,

You are completely free to adapt existing or create your own xslts to drive the HTML generation, though you will also have to arrange somehow for the property labels that you want to use to make it into the result graph from the view query. I can't think of a way to do that by configuration.

There is also an early version of a Velocity based renderer in version 1.2.6 but you'll need to look in the documentation for driving instructions.

Stuart