[Crm-sig] How to represent the textual content of documents about museum objects?
conal.tuohy at gmail.com
Thu Sep 10 09:06:50 EEST 2015
Thanks again Richard!
I have taken your advice and avoided XML Literals. I would appreciate any
comments or criticisms of my new alternative.
To recap, there are "articles" which I have modelled as instances of E31
Document. These used to have rdf:value properties which were XML Literals
containing the HTML text of the article.
Now I've discarded those properties, and instead I'm minting a distinct URI
for those HTML documents, and I decided to utilise the FRBRoo ontology to
link each E31 Document to its own HTML resource, using the FRBR
R4_carriers_provided_by predicate. This means that implicitly the HTML
document containing the article text is an F3 Manifestation Product Type,
and the "article" resource is now an F2 Expression as well as an E31
For example, here is one such "article": <
here's the text of that article: <
I'm not that clear how best to consider this in terms of FRBRoo. It seemed
to me that my "article text" resources are essentially HTML in nature, and
mono-lingual (in English), hence Expressions rather than Works. The
pipeline which returns the HTML HTTP response is a factory of identical (or
near enough) bitstreams, hence Manifestation Product Type.
On 9 September 2015 at 19:46, richard at light.demon.co.uk <
richard at light.demon.co.uk> wrote:
> I don't think that many Linked Data clients will be set up to work with
> XML literals. I would go for a simple wrapper to create a well formed
> document. RDF is not at its best when dealing with string values - witness
> all definitions in dbpedia and SKOS resources, which ought to have
> structure but can't.
> Richard Light
> Sent from my phone
> ----- Reply message -----
> From: "Conal Tuohy" <conal.tuohy at gmail.com>
> To: "Richard Light" <richard at light.demon.co.uk>
> Cc: "CRM SIG" <crm-sig at ics.forth.gr>
> Subject: [Crm-sig] How to represent the textual content of documents about
> museum objects?
> Date: Wed, Sep 9, 2015 05:53
> On 8 September 2015 at 19:05, Richard Light <richard at light.demon.co.uk>
>> Your approach seems perfectly reasonable to me, in the context of an
>> RDF/XML serialization. Presumably it might present problems in other
>> serializations, e.g. Turtle, when you get to the point of offering more.
> Thanks Richard! I hadn't even considered the possibility that the XML
> literal might be a problem in other RDF serializations. I will look into
>> Another way of doing it might be to treat the article as a free-standing
>> information resource, mint a URL for it, and create RDF metadata which
>> describes this resource. Your proxy software would have to resolve the URL
>> and serve up the HTML when requested, but I assume that wouldn't be hard.
> Yes that is the other option I considered, and as you say, it would not be
> In the JSON which the Museum API provides these HTML fragments are not
> even complete HTML documents; or even well-formed documents; they are just
> a sequence of <p> elements. I think any real user interface would want to
> integrate them into a larger page, with a title, images, etc; that's at
> least partly why I chose to encode them just as literal fragments, rather
> than to promote them into being resources in their own right.
> But it's difficult to get a picture of which might actually be a useful
> approach for a Linked Data client.
> Conal Tuohy
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig