- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 18 May 2012 09:38:43 +0200
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Toby Inkster <tai@g5n.co.uk>, W3C RDFWA WG <public-rdfa-wg@w3.org>
On May 18, 2012, at 06:48 , Gregg Kellogg wrote: > On May 17, 2012, at 9:06 PM, "Ivan Herman" <ivan@w3.org> wrote: > >> >> On 18 May 2012, at 04:50, Gregg Kellogg <gregg@greggkellogg.net> wrote: >> >>> I updated my processor to handle embedded RDF/XML and to parse the content of script elements having an @type which matches a content-type of an available RDF parser (typically text/turtle, but why not application/ld+json?). >> >> Out of curiosity: is it a default behaviour in your processor or optional? At the moment my processor does that for turtle only if a special flag is turned on. > > Default. Not much of a risk of emitting triples by accident. > >>> I also added support for putting extracted triples in a named graph based on using any @id value of the script element as a fragid on the document location. >>> >> >> There were some discussion about this usage of @id of the script element on the RDF mailing list, but the results are inconclusive. There are issues in general reusing host language attributes in this way... > > It was suggested in the reference Tony sent, which was really more about N3. Again, the odds of a script tag with both a matching @type and @id seems pretty negligible. Plus, the parser emits statements. A graph context is dropped if their added to a container that doesn't support contexts. The issue is that user may use the @id for totally different purposes. Eg, if I want to add some sort of a javascript to my page that would also want to, say, show the turtle content on the screen, then a reasonable approach is to use the @id attribute on the <script> element and let the Javascript locate the element using that @id. Nothing to do with the graph structure in RDF, but would nevertheless redirect the RDF content into a separate graph. I think we have learnt that reusing existing attributes may lead to issues... Ivan > > Gregg > >> Ivan >> >>> Gregg >>> >>> On May 17, 2012, at 7:09 AM, Gregg Kellogg wrote: >>> >>>> Well, if we're open to having tests that span formats, was should consider parsing Turtle marked up using <script type="application/turtle"> within HTML, at least when the Turtle spec is more settled. >>>> >>>> I hadn't considered the embedded RDF/XML before, but it should be easy enough to add to my parser. >>>> >>>> Gregg Kellogg >>>> >>>> Sent from my iPad >>>> >>>> On May 17, 2012, at 3:33 AM, "Toby Inkster" <tai@g5n.co.uk> wrote: >>>> >>>>> <test-cases/0310> dc:contributor "Toby Inkster"; >>>>> dc:title "Embedded chunks of RDF/XML"; >>>>> a test:TestCase; >>>>> rdfatest:rdfaVersion "rdfa1.0", "rdfa1.1"; >>>>> test:classification test:required; # ?! >>>>> test:expectedResults "true"^^xsd:boolean; >>>>> rdfatest:hostLanguage "svgtiny1.2", "svg"; >>>>> test:informationResourceInput <test-cases/0310.html>; >>>>> test:informationResourceResults <test-cases/0310.sparql>; >>>>> test:purpose "Tests that embedded RDF/XML is added to same graph."; >>>>> test:specificationReference >>>>> "http://www.w3.org/TR/SVGTiny12/metadata.html#Introduction >>>>> says 'an RDF processor should combine them into the same graph'" . >>>>> >>>>> -- >>>>> Toby A Inkster >>>>> <mailto:mail@tobyinkster.co.uk> >>>>> <http://tobyinkster.co.uk> >>>>> >>>>> <0310.sparql> >>>>> <0310.txt> >>>> >>> > ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Friday, 18 May 2012 07:35:36 UTC