Not sure I would like running across dcterms:description with a URI as
its object. Not that dcterms:description has a defined range, but I
don't think most agents would expect anything other than some kind of
text. Linked data is based at least as much on convention as schema -
doing something that disrupts the assumptions of the majority of your
consumers seems counterproductive.
It'd be like having a URI for dcterms:title (also technically legal):
how abstract do you need it?
I personally prefer rdf:XMLLiteral (and an untyped, unmarked up
version would make sense, too).
On Thu, Jan 12, 2012 at 11:26 AM, [log in to unmask] <[log in to unmask]> wrote:
> My inclination would be to keep the descriptive snippets in some kind of content store with a good RESTful Web exposure and just use those URLs as the values of "description" triples in your RDF. Then your RDF is genteel Linked Data and your XHTML can be easily available to integrating services.
> A. Soroka
> Online Library Environment
> the University of Virginia Library
> On Jan 11, 2012, at 11:00 PM, CODE4LIB automatic digest system wrote:
>> From: Ethan Gruber <[log in to unmask]>
>> Date: January 11, 2012 3:07:16 PM EST
>> Subject: Re: Embedding XHTML into RDF
>> People are going to use the YUI rich text editor and the output is run
>> through tidy, so that should ensure the well-formedness of the HTML.
>> Right now we have a system where thousands of small XHTML fragments exist
>> as text files in a filesystem (edited manually, practically), which are
>> rendered through wiki software. The fragments have RDFa attributes so that
>> an RDFa python script can interpret wiki pages as RDF on the fly. We need
>> to redesign the system from the ground up, and I'd like to use RDF as the
>> source object.