- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 08 Apr 2010 18:34:45 -0400
- To: RDFa Working Group WG <public-rdfa-wg@w3.org>
On 04/08/10 14:10, Toby Inkster wrote: > However, if the profile document returns a 404, If the document returns a 404, then IMHO, we need to signal the consuming application via the RDFa Processor that a profile document failed to be retrieved, and then give it the option of stopping or continuing processing of the document. > then it results in: > > _:x a <foaf:Person> . > _:x <foaf:name> "Joe Bloggs" . > _:x <http://example.com/foo> "Bar" . > > i.e. the prefix "foaf:" is treated as a URI scheme, not a CURIE prefix. Hey, looking at this again - it's not that bad, is it? I mean, if we have <foaf:Person> - the likely hood that it's a URI (today) is almost next to none. A post-processing application could come through and expand all non-standard URIs, like foaf:Person, to the "proper" foaf URI. Even better, we generate those triples into a separate "resolve this later" graph and store the active @profile values with the triples that are generated. Yes, that's ugly and not ideal- but I had not noticed that this accomplishes effectively what others have been asking for - allow deferred resolution of invalid triples. I think that the main thing to keep in mind is that we can detect when the parsing goes sour - it's very deterministic. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarming Goes Open Source http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/
Received on Thursday, 8 April 2010 22:35:13 UTC