......
<dbpprop:years rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1889</dbpprop:years> <dbpprop:years xml:lang="en">300.24m</dbpprop:years>
Hello
I'm having a couple of issues with the Eiffel-Tower example on viejs.org:
- 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!
--
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
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
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 ;)
--
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.
> • 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?
> • 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).
> • 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.
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.
--