- From: Peter Danielsen <wiscal@gmail.com>
- Date: Thu, 11 Oct 2012 12:47:39 -0500
- To: public-rdfa@w3.org
- Message-ID: <CADyMoSyW5wJVJP1SO5vm-ibtdLXmNtVaWxHoKV+3P358N0y40Q@mail.gmail.com>
Hi, I have an example where I'm using a prefix whose reference is a relative path, e.g. <body prefix="ex: http://example.com/schema# ovw: overview.html#"> ... <link rel="ex:r" resource="ovw:o1" /> ... </body> I get different results for the triples I get back from different RDFa processors. If the document is at http://www.example.com/index.html, one RDFa processor will say that the object's IRI is "overview.html#o1", and the other will say its "http://www.example.com/overview.html#o1". My expectation is that it's the latter, the absolute IRI, based on the start of 7.4: "Since RDFa is ultimately a means for transporting RDF, a key concept is the *resource* and its manifestation as an IRI. RDF deals with complete IRIs (not relative paths); when converting RDFa to triples, any relative IRIs *must* be resolved relative to the base IRI, using the algorithm defined in section 6.5 of RFC 3987 [RFC3987<http://www.w3.org/TR/2012/PR-rdfa-core-20120508/#bib-RFC3987>], *Reference Resolution*." and the "blue box" just before 7.4.1: "Note that it is generally considered a bad idea to use relative paths in prefix declarations. Since it is possible that an author may ignore this guidance, it is further possible that the IRI obtained from a CURIE is relative. However, since all IRIs must be resolved relative to base<http://www.w3.org/TR/2012/PR-rdfa-core-20120508/#T-base>before being used to create triples, the use of relative paths should not have any effect on processing." I'd like to verify that my expectation is correct. Thanks, Peter (The reason I'm using a relative path is so that a group of documents can be moved from one location to another without having to update the documents to change their prefix mappings. It's useful for validation at a staging location before moving to a production server.)
Received on Friday, 12 October 2012 12:19:51 UTC