- From: Rob Hoare <public-linked-json@robhoare.com>
- Date: Thu, 25 Apr 2013 16:51:12 -0700
- To: public-linked-json@w3.org
I have a basic question about json-ld. I hope this is right place to post it. I have an application where I'm looking at using json-ld contexts to mark up documents that arrive from a variety of sources, to eventually compare, de-duplicate, and link items within them. I'm confused as to whether Type Coercion in json-ld is intended to be helpful for this. To take an oversimplified case, a date may arrive in a variety of formats, depending on the document source. I need a way to put the dates in a standard format (ISO8601) for comparison. If the date contains something like 2000-12-31, I can just use in the @context: "@type": "http://www.w3.org/2001/XMLSchema#date" (as an aside: what is type coercion supposed to do if the data isn't actually in the right format?). More likely, the date is in older formats like "12-31-2000", "31 Dec 2000", and so on. Let's say there's a web service to convert these dates, like: http://example.com/date/us-to-iso/{date} (where {date} is the US date, and the result returned is ISO8601). Is json-ld intended to allow the IRI specified within the @type to be a callable service that can produce a result based on the @value of the field? An IRI with a query string or parameter really. If so, what would be the syntax in this case? If not, is anybody aware of a json-ld (or just json) compatible method or standard for specifying (and running) data transformations that use APIs within a json document? Something like : "ISOdate":"http://example.com/date/us-to-iso/'Date'" (where 'Date' contains the value of the key with that name). This isn't just for dates, it would apply to any incoming field that needs to be transformed or produce derived fields, for example calling a geocode service with a placename to generate co-ordinates. It would be useful to specify as much of this as possible within a @context file (or similar) for each incoming data source, rather than embedding it in code. Any suggestions for the best approach to use would be helpful. Thanks, Rob
Received on Saturday, 27 April 2013 17:52:55 UTC