- From: Michael Hausenblas <michael.hausenblas@deri.org>
- Date: Thu, 29 Oct 2009 11:08:50 +0000
- To: "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com>
- CC: Public RDFa <public-rdfa@w3.org>
Constantine, > Any thoughts on this? I can understand it if it's considered an abuse of RDFa > to try to carry arbitrary metadata, but part of the attraction of RDFa for me > is the idea of avoiding having to create a parallel .rdf file resource for a > resource by carrying all metadata as RDFa. Yes, this is an interesting question. We are collecting issues around this and you might want to check out [1]. IMHO it is ok to have not all RDF embedded, under certain circumstances ... Cheers, Michael [1] http://ld2sd.deri.org/lod-ng-tutorial/#checklist-usability -- Dr. Michael Hausenblas LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html > From: "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> > Date: Thu, 29 Oct 2009 12:01:16 +0100 > To: Public RDFa <public-rdfa@w3.org> > Subject: Carrying all of a resource's metadata as RDFa? > Resent-From: Public RDFa <public-rdfa@w3.org> > Resent-Date: Thu, 29 Oct 2009 11:03:56 +0000 > > We know that RDFa can be used very effectively to semantically tag content > that already exists within a resource - for example, a text node within an > XHTML document tree. > > But what if you want to carry ALL of a resource's metadata within it as RDFa, > even though that metadata has object literals that should not be visible > within the rendered document? Something like this might be worthwhile if you > want to simplify the creation and delivery of content + metadata by merging it > in a single XHTML resource. > > For example, let's say we want the following RDF - basically defining a > date-range in which a resource is "applicable" - to be carried within the same > resource that it refers to: > > <> xyz:applicablePeriod _:a . > _:a rdf:type xyz:Period > _:a xyz:startDate "blah"^^rdf:XMLLiteral > _:a xyz:endDate "blah"^^rdf:XMLLiteral > > This suffers from two problems: > 1. you need some sort of nested element structure to code this > 2. the object literals (XMLLiteral, just for the sake of argument) must not > display within the rendered document > > It would seem logical to put this sort of metadata in the <head> of a > document, but since that only allows a flat structure it seems to be > impossible with RDFa. On the other hand, you could put it in a dedicated <div> > / <span> structure, but then you are forced to add content to the document > that you do not want to display. > > <div rel="xyz:applicablePeriod"> > <span typeof="xyz:Period"> > <span property="xyz:startDate" > datatype="rdf:XMLLiteral">blah</span> > <span property="xyz:startDate" > datatype="rdf:XMLLiteral">blah</span> > </span> > </div> > > Any thoughts on this? I can understand it if it's considered an abuse of RDFa > to try to carry arbitrary metadata, but part of the attraction of RDFa for me > is the idea of avoiding having to create a parallel .rdf file resource for a > resource by carrying all metadata as RDFa. > > Thanks for comments, > Constantine > > ________________________________ > This email and any attachments may contain confidential or privileged > information > and is intended for the addressee only. If you are not the intended recipient, > please > immediately notify us by email or telephone and delete the original email and > attachments > without using, disseminating or reproducing its contents to anyone other than > the intended > recipient. Wolters Kluwer shall not be liable for the incorrect or incomplete > transmission of > of this email or any attachments, nor for unauthorized use by its employees. > > Wolters Kluwer nv has its registered address in Alphen aan den Rijn, The > Netherlands, and is registered > with the Trade Registry of the Dutch Chamber of Commerce under number > 33202517.
Received on Thursday, 29 October 2009 11:09:28 UTC