W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2003

Re: Attaching (embedding?) RDF

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Tue, 28 Oct 2003 12:06:35 +0200
To: ext Jeremy Carroll <jjc@hplb.hpl.hp.com>, Martin May <maym@foobar.lu>, Rahul Singh <kingtiny@cs.cmu.edu>
Cc: <www-rdf-interest@w3.org>
Message-ID: <BBC40C4B.392C%patrick.stickler@nokia.com>


While I generally favor managing metadata separate from resources,
this sounds like it would be a very general solution, in that a
single extraction tool could be created which scans any input
stream for RDF/XML instances. This simplifies the embedding issue
to simply how to embed the RDF/XML within the encoding in question.

Of course, there remains the problem of knowing whether, or which,
RDF/XML instance embedded within a given resource actually describes
the resource in question...

Patrick


On 2003-10-28 11:57, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com> wrote:

> 
> 
> A workable hack on the embedding front (option 3) is to do a linear search
> of the file for the rdf:RDF tag, ideally this needs to be smart i.e. a
> search for
> "<" + NCName + ":RDF" + whitespace + other xml attributes + "xmlns:" +
> NCName + whitespace + "=" + whitespace + ["'] +
> http://www.w3.org/rdfnamespaceuri# +["'] + other xml attributes + ">"
> 
> One needs to assume UTF-8 or UTF-16 encoding.
> 
> A linear search for the namespace uri can be quite efficient (I don't have
> the reference for the technique for searching for a long fixed substring,
> but you only have to look at a few of the characters). You then need to work
> back from there to see if the rdf:RDF matches.
> 
> The idea is that at first approximation all embeddings are the same and one
> doesn't need to know the master file type.
> 
> Jeremy
> 
>> -----Original Message-----
>> From: www-rdf-interest-request@w3.org
>> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Martin May
>> Sent: 27 October 2003 20:14
>> To: Rahul Singh
>> Cc: www-rdf-interest@w3.org
>> Subject: Re: Attaching (embedding?) RDF
>> 
>> 
>> 
>> 
>> Yes,
>> 
>> I actually looked at XMP, and it seems that they are using method #3
>> (please correct me if I'm wrong). IMHO the drawback of not being able
>> to store metadata in a generic way and having to write custom adaptors
>> for every file type is quite a big one. On top of that, some file types
>> don't support embedded metadata at all.
>> 
>> I was hoping that somebody would know of some alternatives to the ones
>> that I presented or know of methods to overcome the drawbacks.
>> 
>> Thanks,
>> 
>> Martin
>> 
>> On 27 Oct 2003, at 18:43, Rahul Singh wrote:
>> 
>>> Have you looked at Adobe XMP?
>>> 
>>> http://www.adobe.com/products/xmp/main.html
>>> 
>>> Cheers,
>>> 
>>> Rahul
>>> 
>>> Martin May wrote:
>>> 
>>>> 
>>>> 
>>>> I would like to attach RDF metadata to files. So far I have
>>>> identified the following options for doing so, all of which have
>>>> drawbacks:
>>>> 
>>>> 1. given a file foo.pdf, store the metadata in a file foo.pdf.rdf in
>>>> the same directory
>>>> 
>>>> Main drawbacks:
>>>> 
>>>> - if the file is moved or renamed, the metadata must be moved with it
>>>> 
>>>> 2. store the metadata in a central repository, with a link (URI) to
>>>> the file
>>>> 
>>>> Main drawbacks:
>>>> 
>>>> - again, if the file is moved or renamed, the link becomes invalid
>>>> - requires a central repository
>>>> 
>>>> 3. embed the metadata in the file format
>>>> 
>>>> Main drawbacks:
>>>> 
>>>> - doesn't work with every file type
>>>> - different handling for each file type required
>>>> 
>>>> 4. create an archive file which groups the file and its metadata
>>>> (e.g. jar)
>>>> 
>>>> Main drawbacks:
>>>> 
>>>> - requires unpackaging and repackaging every time the file needs to
>>>> be accessed
>>>> 
>>>> Does anybody have any insights or ideas on how to improve the
>>>> suggested methods, or provide me with other alternatives?
>>>> 
>>>> Best regards,
>>>> 
>>>> Martin May
>>>> University of Aberdeen
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
Received on Tuesday, 28 October 2003 05:06:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:02 GMT