- From: c.d.r. <_@whats-your.name>
- Date: Fri, 7 Sep 2007 17:02:32 +0000
- To: semantic-web@w3.org
> { > "uri" : "http://...#alec", > "http://xmlns.com/foaf/0.1/name": "Alec Tronnick", > "http://xmlns.com/foaf/0.1/knows": [ > {"uri": "http://...#john"}, > {"uri": "http://...#bob"} > ] > } > ? yep, thats it exactly. we dont care if its just a 'uri' or a 'resource' in the object position, leaving the option open for nesting - i agree flat is usually the choice, except eg a query that returns friends up to 3 degrees of seperation apart - fresnel. no point in flatting down after your query and re-treeing on the client side just beacuse someones JSON format says you must.. > How do you define a bnodeID and re-use it, so that you can avoid > duplication? Do you set the "uri" key to "_:b1"? (In that case > the key name should prolly be changed to "id" or something similar) Simile does have a 'uri' and an 'id' key. Metaweb also has a UUID that exists regardless of the node having a (relative to freebase) URI or not - so at least two groups have found an 'id' key useful. bnodes that dont have IDs are kept in-place. so you need the full path (subj and pred) to find them again.. those are useful for things like language tags: {'http://rdfliteral/locale/en_us': 'Hello', 'http://rdfliteral/locale/fr':'Bonjour'}. its clear they are different translations of the same object, and that fact is expressed in RDF.. > > How do you get the prop values of a known resource w/o > having to loop through the array? This is one of the > advantages I see in the RDF/JSON proposal, being able to do > name = resources["http://...#alec"]["http://.../name"][0]["value"] > without the need for FORs, IFs or structure checks. when theyre cached in the agent, just append them to a 'resources' object keyed on the uri so they can be referenced like that. once youve 'looked up' the object, you still have the URI property, so you dont need to keep that in a closure or a special 'rdf resource' wrapper class in your app/library.. > however, are cases where literals have types that go > beyond JSON's built-ins, e.g. "foo"^^ex:someDatatype, there is a URI for ex:someDataType. you can use 'literal bnodes' as mentioned above to handle with this, without breaking down to those nasty 'literal' and 'value' and 'datatype' fields that surely signal youre doing something wrong (for one, keeping some of your model outside of triple-space, and in serialization-space. a problem with RDF/XML that seems to have leaked over to Keiths proposal) cr
Received on Friday, 7 September 2007 21:04:48 UTC