W3C home > Mailing lists > Public > public-wai-ert@w3.org > June 2010

Re: Content in RDF Question

From: Johannes Koch <johannes.koch@fit.fraunhofer.de>
Date: Tue, 29 Jun 2010 10:38:44 +0200
Message-ID: <4C29B114.60709@fit.fraunhofer.de>
To: ERT WG <public-wai-ert@w3.org>
Hi group

Robert Sanderson schrieb:

> 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.
> 1.
> 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.

To be precise it's not about a file, it's about an RDF resource with the 
URI "....png" or "....css". There's no requirement for a file to exist 
somewhere when requesting the URI.

>  For example,
> using content negotiation, a resource may have multiple
> representations at the same time.

See HTTP-in-RDF.

>  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
> resource?
> 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.

If the RDF resources' URIs (rdf:about value) are the same, both parts of 
information (the one using ContentAsText and the other using 
ContentAsXML) describe the same thing. If both parts of information do 
not describe the same thing, the URIs (rdf:about values) should be 

> 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.

The three RDF resources in example 2.1 describe different things 
(different serializations) and so have different URIs.

> 2.
> 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 ]
> Thus:
>     :original dct:hasFormat :new .
>     :new a cnt:ContentAsText , ...

This could be a good idea.

> 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.

Again: See HTTP-in-RDF

> Many thanks,
> Rob Sanderson,
> Los Alamos National Laboratory

Johannes Koch
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628    Fax: +49-2241-142065
Received on Tuesday, 29 June 2010 08:39:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:59 UTC