Re: Uniform access to descriptions

Michaeljohn Clement wrote:
> Xiaoshu Wang wrote:
>   
>>>> We agree that there are legacy data, yes?  Let's make its URI x, whose
>>>> owner is Joe.
>>>> Case 1. Joe is lazy.
>>>> Then, no LINK, no Conneg. Is this fair?
>>>> Case 2: Joe is not lazy.
>>>> (a) Joe makes LINK(x)=metadata.
>>>> (b) Joes make Conneg(x)=metadata (can easily GET x Accept
>>>> application/rdf+xml).
>>>>         
>>> (b) would be wrong, because the metadata is not an alternative variant
>>> of the resource identified by x.
>>>   
>>>       
>> Why wrong? First define metadata?  Say _:x _:b _:y.  Is this assertion
>> metadata of _:x or _:b or _:y?  You assume it is wrong because of an
>> arbitrary definition of metadata. 
>>     
>
> I object on the basis of my sense of what conneg is for.  I don't believe 
> my definition of "metadata" is relevant.
>
> Let's stipulate that GET x, for the "x" in your example, returns a PNG 
> image, and that the metadata in question is some statements about that 
> image, expressed in RDF.
>
> Would you not agree that the RDF represents a different resource from 
> the image?
>   
Content-negotiating PNG and SVG logos seems entirely reasonable. 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.

> Content negotiation would be an appropriate way to serve an alternative 
> JPEG representation of the same resource, but to return a different 
> resource would be contrary to accepted and expected usage.
>   
Do you object to bitmap and vector representations of the same abstract 
logo being served from same conneg URI? (forget RDF for a moment...)
>> In your proposal, any RDF
>> transformation is the metadata of an HTML, they should be put in LINK too.
>>     
>
> I'm not proposing that.  I am simply suggesting not to use conneg except 
> to negotiate between different representations of the same resource.
>   
I've never found a sustainable definition that keeps 'representation' 
apart from 'description'; it seems a matter of degree, when dealing with 
digital information at least.

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. They won't be equally useful to 
everyone, but they are manifestations of the same expression of some 
creative work - to use FRBR concepts - http://en.wikipedia.org/wiki/FRBR 
this would be

[[
Group 1 entities are the foundation of the FRBR model:

* Work is a “distinct intellectual or artistic creation.” (IFLA 1998)

* Expression is “the specific intellectual or artistic form that a work 
takes each time it is ‘realized.’” (IFLA 1998)

* Manifestation is “the physical embodiment of an expression of a work. 
As an entity, manifestation represents all the physical objects that 
bear the same characteristics, in respect to both intellectual content 
and physical form.” (IFLA 1998)

* Item is “a single exemplar of a manifestation. The entity defined as 
item is a concrete entity.” (IFLA 1998)
]]

On this model, a graphic designer creates a Work, ie. the logo. This may 
go through some iterative design tweaks, each corresponding to a 
specific expression which may have in turn multiple manifestations as 
content-typeable collections of bytes. Finally, "Item" would correspond 
to actual instances of those bytes streaming around the network or a 
computer.

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

cheers,

Dan

--
http://danbri.org/

Received on Saturday, 12 April 2008 11:27:45 UTC