W3C home > Mailing lists > Public > public-earl10-comments@w3.org > June 2010

Content in RDF Question

From: Robert Sanderson <azaroth42@gmail.com>
Date: Thu, 10 Jun 2010 09:00:51 -0600
Message-ID: <AANLkTikm-0gZ3jdcIE4WYyM3ppMm4ez7eawX89IWUhz5@mail.gmail.com>
To: public-earl10-comments@w3.org
Cc: Herbert van de Sompel <hvdsomp@gmail.com>, t-cole3 <t-cole3@illinois.edu>
Dear List,

We are interested in using the Content in RDF specification for work
with Annotations on the Web (project home page:
www.openannotation.org), however have some questions about the usage
of the ontology.


The examples show the properties attached to the original resource's
URI.  In example 2.2, the description is rdf:about the .png file.  In
example 2.3, the description is rdf:about the .css file.
This seems to be conflating resource and representation.  For example,
using content negotiation, a resource may have multiple
representations at the same time.  Across time a resource is very
likely to have many different representations.  Shouldn't each
cnt:ContentAs* have its own unique URI, separate from the original

This also prevents multiple parties from independently expressing the
Content of a resource in separate ways and having them collide.  For
example, one party uses ContentAsText and another ContentAsXML. Or
with different encodings, or at different times.  When those are
aggregated, the properties and relationships merge into
meaninglessness, even though they are independently true.

In example 2.1, there are new URIs generated for derived
serializations, related back to the original serialization/resource
with dcterms:source.  This seems to be half way towards the correct
solution of new URIs for each ContentAs* resource, with a relationship
to and/or from the original.


As to the relationship, it would be nice if it could be expressed in
either direction, and dcterms:source does not have an inverse
relationship, such as isSourceOf.  Other dcterms properties to
consider would be hasFormat/isFormatOf:
  "A related resource that is substantially the same as the
pre-existing described resource, but in another format."
[ http://dublincore.org/documents/dcmi-terms/#terms-hasFormat ]

    :original dct:hasFormat :new .
    :new a cnt:ContentAsText , ...

If Pete Johnson is still on the list, perhaps he might have some
comments on this matter?

Equally a specific cnt:hasRepresentation relationship would be more
specific and perhaps more appropriate.
    :original cnt:hasRepresentation :new .
    :new a cnt:ContentAsText , ...

Where the domain is rdf:resource, and the range is cnt:Content.

Many thanks,

Rob Sanderson,
Los Alamos National Laboratory
Received on Thursday, 10 June 2010 15:01:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:39:57 UTC