Re: ref'ing data from metadata in same doc

> Say you have an RDF doc on the web. To talk about the resource the doc
> represents you can use rdf:about="". But what if the representation
> has both data (representation of the resource) and metadata
> (description of the resource) parts:

Here's one point of view (I'm not saying it's right!). Treat this as  
if you just got handed two representations of the resource you  
requested: one in FLAC without metadata, and one in RDF. The RDF,  
referencing "" or "#", naturally refers to the resource you requested.

The only thing I see as being difficult is if you would like the  
metadata to refer both to the resource (title, artist) *and* the  
particular representation in which it is embedded (size, byte order,  
or whatever).

> ( (data)  (metadata rdf:about="") )
>
> The concrete example I've run up against relates to FLAC, the Free
> Lossless Audio Codec [1]. (The format already has a bunch of fairly
> preset metadata blocks, I've suggested they allocate one for RDF). If
> you do a GET for type "audio/x-flac", you'll get the whole thing. The
> metadata implicitly will also be about itself - is that sane?

Intuitively (at least to me) the metadata will be about a resource of  
which this is a representation. I think that's how XMP does it --  
you're not describing how big the PDF is, or what font it uses,  
you're describing the attributes of the document.

> Might rdf:about="#" be a workaround..?

Possibly. I'd be inclined to use "#" to describe the resource, and  
then try to use some vocabulary  to link it to the representation,  
which remains unnamed (or vice versa). An alternative is to try to  
use fragments to address the representation ("#metadata").

I don't know a good answer.

> For this particular case the issue is probably
> sweep-under-the-carpetable. (Hmm, anyone happen to know how it's done
> in Adobe's XMP?) But where I'm getting puzzled is where the RDF is
> deeply embedded, for example with eRDF or RDFa. Is the embedded data
> generally about the doc, or should it be considered an alternate
> representation of the doc?

I'd be inclined to say the latter, but that leaves the problem of  
dealing with the former.

-R

Received on Sunday, 1 October 2006 14:34:56 UTC