Re: Uniform access to descriptions

Dan Brickley wrote:
> Content-negotiating PNG and SVG logos seems entirely reasonable.

Sure.

> And the
> SVG can have bits of RDF in it (as can the PNG, eg. see
> http://www.tasi.ac.uk/2000/09/rdfmeta/ or Adobe's XMP system). RDF for
> that matter can be a carrier for SVG, either in custom properties or in
> XML literals. While I'm not saying that any RDF description of an image
> will be a suitable alternate for the PNG, it's quite feasible that bits
> of SVG inside RDF could be usefully consumed *by some clients*. And
> after all that's what conneg is all about. See
> http://www.jibbering.com/2002/3/nadiaeric.rdf for some example experiments.

I didn't mean to say that RDF in JPEG, or SVG in RDF, or anything else 
is fundamentally wrong for conneg, but rather to suggest a hypothetical 
case where the RDF is clearly a distinct resource that is in some sense 
"about" the image.  Perhaps I should have said it is about the JPEG, e.g. 
metadata, or file creation time.

> Do you object to bitmap and vector representations of the same abstract
> logo being served from same conneg URI? (forget RDF for a moment...)

No.  I won't even object to pure RDF and JPEG being content-negotiated 
at the same URI, if there is a reason to regard them as representations 
of the same resource.  For example, the JPEG may be a chart, and the RDF 
may be a machine-readable analogue to HTML's longdesc.  It may convey the 
same meaning as the JPEG would to a normally sighted human viewer, without 
reliance on the capacity for visual apprehension in the processing agent.

> To me, an SVG vector image, and a visually identical (for most sighted
> users in most graphical browser) PNG or JPEG are reasonable
> 'alternatives' in the conneg sense. 

Agreed.

> They won't be equally useful to
> everyone, but they are manifestations of the same expression of some
> creative work

More to the point, for me, they are representations of the same 
resource.  It would not want to say that resource is simply the 
"creative work" in the FRBR sense.  The resource may be e.g. 
"example.com's photo of the day".

> - to use FRBR concepts - http://en.wikipedia.org/wiki/FRBR
> this would be
> [...]

Work in that sense is not the same concept as awww:resource.

(Though certainly a URI could be minted for a Work, and then it would be 
a resource.  But not necessarily an information resource.  The David 
does not answer your HTTP requests.)

> My thinking about REST and HTTP-range is unashamedly shaped by FRBR's
> influence in the digital library community. I wonder how well it
> resonates with others here. But I do think it does explain why I'm quite
> happy with the PNG and JPEG sharing a conneg URI...

I guess the "common understanding" (as I see it) of awww:resource and 
awww:representation can accommodate your view of conneg, but is not 
identical with it.

Michaeljohn

Received on Saturday, 12 April 2008 20:47:45 UTC