VIE Eiffeltower example

113 views
Skip to first unread message

Reto Bachmann-Gmür

unread,
Mar 1, 2012, 11:42:26 AM3/1/12
to vi...@googlegroups.com
Hello

I'm having a couple of issues with the Eiffel-Tower example on viejs.org:

- Why is one URIRef (the one for the resource) used as string while the one used as a property used in a string armoured with '<' and '>', as properties are resources too, this seems to be an inconsistency.

- I can't find a proper definition of http://dbpedia.org/property/years but it seems to be used quite weirdly both to point to a year as well as too a string describing a height. From dbpedia I get:
...
<dbpprop:years rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1889</dbpprop:years> <dbpprop:years xml:lang="en">300.24m</dbpprop:years>
...

The interpretation "Eiffel Tower, at 1889 was 300.24m tall" seems to have no bases from these triples (it could as well be the other way round, or if some datatype interpretation excludes this we could have 4 dbpprop:years properties making it impossible to see which year relates to which height).

- Where does the order of property values as used in `year: entity.get(heightByYear)[1], height: entity.get(heightByYear)[0]` come from? are the values sorted by datatype?

- How does vie handle the different datatypes, the examples treats the height as string and has to remove quotes and language tag, wouldn't it make sense to return an object with a value and a language property?

Cheers,
Reto

Sebastian Germesin

unread,
Mar 2, 2012, 3:09:55 AM3/2/12
to vi...@googlegroups.com
Hi Reto,

thanks for your input on that. But, I don't get your point here. Do you question the example itself? Which is just intended to show how to query dbpedia for some properties... Do you question the DBpedia database and their inconsistency of property names and their meaning? If so, this is the wrong forum ;)

However, I agree that the example might be misleading in a certain way, maybe we could remove the 1889 from the output to make it more clear to the user? Unfortunately, in dbpedia, this is the only property where the height can be retrieved from. Maybe we could instead ask for "When has the Eiffel Tower been completed?" -> 1889 (derived by dbpprop:completionDate).

To your related questions:

- Why is one URIRef (the one for the resource) used as string while the one used as a property used in a string armoured with '<' and '>', as properties are resources too, this seems to be an inconsistency.

-> In most cases, it does not make a difference for VIE if you query for an entity (or property) with surrounding "<",">" as the internal methods expand them where needed. However, we suggest to set them everytime to be on the save side.
BTW: 

var heightByYear1 = '<http://dbpedia.org/property/years>';
var heightByYear2 = 'http://dbpedia.org/property/years';
var heightByYear3 = 'dbprop:years';

A query for all these three different ways of representing a property return the same value.


- Where does the order of property values as used in `year: entity.get(heightByYear)[1], height: entity.get(heightByYear)[0]` come from? are the values sorted by datatype?
-> No, the order is set by the data that we derive and parse from DBPedia.

- How does vie handle the different datatypes, the examples treats the height as string and has to remove quotes and language tag, wouldn't it make sense to return an object with a value and a language property?
-> So far, VIE ignores datatypes. Most of the time, a simple "typeof entity.get(...);" helps. However, this is the correct place to start a discussion about this!

Cheers,
Sebastian

Am Donnerstag, 1. März 2012 17:42:26 UTC+1 schrieb Reto Bachmann-Gmür:
Hello

I'm having a couple of issues with the Eiffel-Tower example on viejs.org:


Szaby Grünwald

unread,
Mar 2, 2012, 10:10:32 AM3/2/12
to vi...@googlegroups.com
Hi,

Related to the dbpedia issue, I think as well, it's a dbpedia problem. Parsing wikipedia articles doesn't define an ontology.
 
- How does vie handle the different datatypes, the examples treats the height as string and has to remove quotes and language tag, wouldn't it make sense to return an object with a value and a language property?
-> So far, VIE ignores datatypes. Most of the time, a simple "typeof entity.get(...);" helps. However, this is the correct place to start a discussion about this!

Good point.. This actually makes us trouble at different points. With rdfquery included, using enhancement or entityhub entities from stanbol feeding all the literals into vie, the literals are converted into turtle format and stored in backbone as such. This is not nice.
I suggest 
  1. We should use the JSON-LD way [1] for storing plain literals: {"@value": "Salzburg", "@language": "de"}
  2. Define the toString() method on these literal objects as `return this["@value"]`, so that we can use `"Label: " + entity.get("dc:title");` which will call the `.toString()` method automatically and return `"Label: Salzburg"`.
  3. If the property has several values like rdfs:label in different languages, the toString() method should find the correct language for the users locale.
Right now I'm trying out a solution that goes in this direction. At least for 1. and 2.

On the long run we could think about supporting xsd data type validation and parsing, using a library like [2].

cheers,
Szaby


--
VIE.js @ Google Groups
 
web: http://viejs.org
list: vi...@googlegroups.com
 
More information can be found at
http://groups.google.com/group/viejs?hl=de?hl=de

Sebastian Germesin

unread,
Mar 2, 2012, 10:36:01 AM3/2/12
to vi...@googlegroups.com
Hi,


Am 02.03.2012 um 16:10 schrieb Szaby Grünwald:

> Hi,
>
> Related to the dbpedia issue, I think as well, it's a dbpedia problem. Parsing wikipedia articles doesn't define an ontology.
>
> - How does vie handle the different datatypes, the examples treats the height as string and has to remove quotes and language tag, wouldn't it make sense to return an object with a value and a language property?
> -> So far, VIE ignores datatypes. Most of the time, a simple "typeof entity.get(...);" helps. However, this is the correct place to start a discussion about this!
>
> Good point.. This actually makes us trouble at different points. With rdfquery included, using enhancement or entityhub entities from stanbol feeding all the literals into vie, the literals are converted into turtle format and stored in backbone as such. This is not nice.

Well, this is not the fault of rdfquery, but the fault of ourselves and the lack of a model for literals. The conversion from the server-response would work seamlessly with rdfquery.

> I suggest
> • We should use the JSON-LD way [1] for storing plain literals: {"@value": "Salzburg", "@language": "de"}

Sounds good, but we would also need an "@datatype" field, don't we?
> • Define the toString() method on these literal objects as `return this["@value"]`, so that we can use `"Label: " + entity.get("dc:title");` which will call the `.toString()` method automatically and return `"Label: Salzburg"`.

I'd rather would like a .toString(lang) method that either gets a string or an array of strings and prints the literal in the way the user/developer wants it to - rather than doing some magic guessing about the user's language.

> • If the property has several values like rdfs:label in different languages, the toString() method should find the correct language for the users locale.


> Right now I'm trying out a solution that goes in this direction. At least for 1. and 2.

Can you please implement literals as proper backbone models with your solution? In that way, we could also have collections of literals which are way easier to handle on the UI than plain arrays of objects (think of inserting new literals, updating, removing literals).

>
> On the long run we could think about supporting xsd data type validation and parsing, using a library like [2].
>
> cheers,
> Szaby

Cheers,
Sebastian

Reto Bachmann-Gmür

unread,
Mar 2, 2012, 12:46:28 PM3/2/12
to vi...@googlegroups.com
On Fri, Mar 2, 2012 at 9:09 AM, Sebastian Germesin <neog...@googlemail.com> wrote:
Hi Reto,

thanks for your input on that. But, I don't get your point here. Do you question the example itself? Which is just intended to show how to query dbpedia for some properties... Do you question the DBpedia database and their inconsistency of property names and their meaning? If so, this is the wrong forum ;)

I think I criticise the following:
- Using this property for the height is relying on a bug in dbpedia, the result is probably correct, but it is so by chance not by some semantic mechanism it (implicitely) claims to apply.
- In RDF there is no such thing as an order of triples of properties, obviously when processing the same serialization with the same deterministic algorithms, the resulting array will be in the same order, but if the functionality of VIE is defined in terms of RDF it is a bug for a client to rely on such an ordering.
- Instead of returning some meaningfull objects for plain literals VIE seems to return their serialization and the hack to work around this problem in the example is very ugly as it presupposes a specific length and format of the value.
- It uses two different syntaxes for URIs (which as you write are both legal), but showing the variety of supported syntax I think is out of scope for a first introductory example

Cheers,
Reto

 

--

Szaby Grünwald

unread,
Mar 5, 2012, 4:33:37 PM3/5/12
to vi...@googlegroups.com
Hi Sebastian,

 Well, this is not the fault of rdfquery, but the fault of ourselves and the lack of a model for literals. The conversion from the server-response would work seamlessly with rdfquery.

You're of course right, but the Turtle strings don't appear if rdfQuery is not loaded, which means the the way we import triples with or without rdfQuery is inconsistent and developer-unfriendly (wrong).


>       • We should use the JSON-LD way [1] for storing plain literals: {"@value": "Salzburg", "@language": "de"}
Sounds good, but we would also need an "@datatype" field, don't we?

Plain literals don't have a specified type, because their type is String. Types literals would have a specified type, but they don't have a language definition as far as I know.

>       • If the property has several values like rdfs:label in different languages, the toString() method should find the correct language for the users locale.
> Right now I'm trying out a solution that goes in this direction. At least for 1. and 2.
Can you please implement literals as proper backbone models with your solution?  In that way, we could also have collections of literals which are way easier to handle on the UI than plain arrays of objects (think of inserting new literals, updating, removing literals).

Until now all backbone models are Entities and all backbone collections are a set of those entities. If I understand you right your suggestion would mean that we'd introduce one or more types of backbone models which are typed and untyped literals and also a new type of backbone collection which is a set of these values, right?

>       • Define the toString() method on these literal objects as `return this["@value"]`, so that we can use `"Label: " + entity.get("dc:title");` which will call the `.toString()` method automatically and return `"Label: Salzburg"`.
I'd rather would like a .toString(lang) method that either gets a string or an array of strings and prints the literal in the way the user/developer wants it to - rather than doing some magic guessing about the user's language.

Indeed the method should be usable in different situations, but when it's called by the javascript interpreter in the above mentioned way, as far it's possible, it should deliver a reasonable, human-readable result.

Szaby

Sebastian Germesin

unread,
Mar 13, 2012, 9:07:13 AM3/13/12
to vi...@googlegroups.com, szaby.g...@web.de


Am Montag, 5. März 2012 22:33:37 UTC+1 schrieb Szaby Grünwald:
Hi Sebastian,

 Well, this is not the fault of rdfquery, but the fault of ourselves and the lack of a model for literals. The conversion from the server-response would work seamlessly with rdfquery.

You're of course right, but the Turtle strings don't appear if rdfQuery is not loaded, which means the the way we import triples with or without rdfQuery is inconsistent and developer-unfriendly (wrong).

>       • We should use the JSON-LD way [1] for storing plain literals: {"@value": "Salzburg", "@language": "de"}
Sounds good, but we would also need an "@datatype" field, don't we?

true
 

Plain literals don't have a specified type, because their type is String. Types literals would have a specified type, but they don't have a language definition as far as I know.

>       • If the property has several values like rdfs:label in different languages, the toString() method should find the correct language for the users locale.
> Right now I'm trying out a solution that goes in this direction. At least for 1. and 2.
Can you please implement literals as proper backbone models with your solution?  In that way, we could also have collections of literals which are way easier to handle on the UI than plain arrays of objects (think of inserting new literals, updating, removing literals).

Until now all backbone models are Entities and all backbone collections are a set of those entities. If I understand you right your suggestion would mean that we'd introduce one or more types of backbone models which are typed and untyped literals and also a new type of backbone collection which is a set of these values, right?

I think if we want to do it correct in terms of semantically correct, we would need three more types VIE.Literal, VIE.TypedLiteral and VIE.UntypedLiteral, where the latter two just inherit from the first type. However, for the sake of simplicity for the developer who has to use these things, one could just implement VIE.Literal as a backbone model and provide methods to instantiate either one of typed or untyped literals?
 

>       • Define the toString() method on these literal objects as `return this["@value"]`, so that we can use `"Label: " + entity.get("dc:title");` which will call the `.toString()` method automatically and return `"Label: Salzburg"`.
I'd rather would like a .toString(lang) method that either gets a string or an array of strings and prints the literal in the way the user/developer wants it to - rather than doing some magic guessing about the user's language.

Indeed the method should be usable in different situations, but when it's called by the javascript interpreter in the above mentioned way, as far it's possible, it should deliver a reasonable, human-readable result.

A while ago, I've implemented this:


Which is currently implemented under VIE.Util and tries to extract a String from a VIE.Entity, given an array of properties and an array of languages to check for. However, this might need some improvements but did the trick at the time needed, so maybe this is a good start to implement Entity.toString() ? We should then also think about Collection.toString() as well.

Szaby Grünwald

unread,
Mar 13, 2012, 12:06:26 PM3/13/12
to vi...@googlegroups.com
In order to solve some a current issue using Stanbol I introduced the following fix:

>       • We should use the JSON-LD way [1] for storing plain literals: {"@value": "Salzburg", "@language": "de"}


If you're using Stanbol and VIE you might have to make sure that your apps are producing the correct labels. What changed:

literal = entity.get(prop) doesn't give you a '"label"@en' kind of string but rather an object where you have to put a .toString() (which is safe for any string anyways), to get the string value. On the other hand you can use literal["@language"] and in the future .getLanguage() to get the literals language.

cheers,
Szaby

Sebastian Germesin

unread,
Apr 3, 2012, 8:12:16 AM4/3/12
to vi...@googlegroups.com
Hi, 

this discussion has been idle for a while.

Could we vote for a solution here and derive an issue on github (or point to an existing one) that someone can start working on this?

Cheers,

Sebastian

Szaby Grünwald

unread,
Apr 4, 2012, 7:27:15 AM4/4/12
to vi...@googlegroups.com
Hi Sebastian,

I agree that we should move towards a long-term solution in this issue.

Around two weeks ago I fixed the urgent issue with literal handling at the point where we parse the rdf coming from stanbol service here and creating a method in Util for getting the best-scored label based on an ordered list of property names and languages here. This aproach works basically as discussed here.

Although it would probably break existing implementations built on top of VIE, we should generalize this approach to all entities and all literals in a way that fixing existing implementations built on top of VIE would be obvious and self-explaining.

cheers,
Szaby

--
Reply all
Reply to author
Forward
0 new messages