|VIE Eiffeltower example||Reto Gmür||3/1/12 8:42 AM|
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:
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), height: entity.get(heightByYear)` 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?
|Re: VIE Eiffeltower example||Sebastian Germesin||3/2/12 12:09 AM|
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:
-> 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.
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.
-> No, the order is set by the data that we derive and parse from DBPedia.
-> 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!
|Re: [viejs] Re: VIE Eiffeltower example||Szaby Grünwald||3/2/12 7:10 AM|
Related to the dbpedia issue, I think as well, it's a dbpedia problem. Parsing wikipedia articles doesn't define an ontology.
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.
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 .
|Re: [viejs] Re: VIE Eiffeltower example||Sebastian Germesin||3/2/12 7:36 AM|
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 suggestSounds 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.
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).
|Re: [viejs] Re: VIE Eiffeltower example||Reto Gmür||3/2/12 9:46 AM|
On Fri, Mar 2, 2012 at 9:09 AM, Sebastian Germesin <neog...@googlemail.com> wrote:Hi Reto,
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
--VIE.js @ Google Groups
|Re: [viejs] Re: VIE Eiffeltower example||Szaby Grünwald||3/5/12 1:33 PM|
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).
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.
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?
|Re: [viejs] Re: VIE Eiffeltower example||Sebastian Germesin||3/13/12 6:07 AM|
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?
A while ago, I've implemented this:
|Re: [viejs] Re: VIE Eiffeltower example||Szaby Grünwald||3/13/12 9:06 AM|
In order to solve some a current issue using Stanbol I introduced the following fix:
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.
|Re: [viejs] Re: VIE Eiffeltower example||Sebastian Germesin||4/3/12 5:12 AM|
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?
|Re: [viejs] Re: VIE Eiffeltower example||Szaby Grünwald||4/4/12 4:27 AM|
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.