W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 1999

RE: A simple question....

From: Stefan Decker <stefan@DB.Stanford.EDU>
Date: Wed, 17 Nov 1999 19:51:53 -0800
Message-Id: <>
To: www-rdf-interest@w3.org
Hi Dan,

could you show how this could for my original problem?
How do i change my editor, such that i can add metadata to HTML pages,
but i don't have to copy the text out of the HTML-page?


At 10:15 PM 11/17/99 -0500, you wrote:
>On Thu, 18 Nov 1999, Renato Iannella wrote:
> > --On 17/11/99 4:30 PM +0200 Ora.Lassila@nokia.com wrote:
> >
> > > Stefan,
> > >
> > > you raise a very interesting question. As I recall, it was actually 
> at one
> > > time discussed in the RDF working group.
> >
> > And I remeber it like it was yesterday ;-)
> >
> > I unsuccessfully argued for a facility in RDF syntax to differentiate
> > between a URI being used to *identify* another resource (which we have
> > now with "resource=" attribute) and a URI that is a link to more RDF
> > that _could_ be dereferenced (with a new attribute "metadata=").
> >
> > For W3C Memebers you review the thread starting at:
> >
> >   http://lists.w3.org/Archives/Member/w3c-rdf-syntax-wg/1998Dec/0007.html
> >
> > I still think that this is a _useful_ facility for the "Semantic Web"
>See also the 'seeAlso' property in RDF schema, which can be used for
>exactly this.
>         2.3.4 seeAlso
>         The property rdfs:seeAlso specifies a resource that contains 
> information
>         about the subject resource. This property may be specialized using
>         rdfs:subPropertyOf to more precisely indicate the nature of the
>         information the object resource has about the subject resource.
>This can be used as a hint in the case of self-describing resources.
>While syntactic abbreviations to tell us about self-describing uses are
>certainly useful, I think it is worth making a point of the fact that
>(a) this is just more metadata about something, and (b) there are a
>variety of ways of acquiring metadata from a URI-named resource which
>we'll want to reflect into RDF. It becomes a slippery slope as to when
>'resource=' versus 'metadata=' would've been appropriate.
>For example: for many resources in the http:* namespace it might be
>appropriate to use the HEAD HTTP method to find out more metadata, or use
>WebDAV facilities, or send a content-negotation mimetype preference of
>(for eg) text/x-rdf to express an interest in an RDF view of the object.
>For resources in the z3950:* URI namespace, your RDF processor might want
>to use other mechanisms, eg. the Z39.50 query protocol's EXPLAIN feature,
>to acquire more RDF statements about the named resource.
>So... hardcoding 'metadata=' into our syntaxes (*not* the
>model) might a be useful abbreviation for '[x]--seeAlso-->[x]', or
>'[x]--dc:format-->"text/x-rdf"'. But figuring out strategies and commonly
>agreeable patterns for acquiring RDF descriptions of a wider diversity of
>resources (eg. HEAD, webDAV, EXPLAIN etc) strikes me as a more fruitful
>An example:
>If I have an MP3 audio file online somewhere, or a JPEG, or whatever
>data format. Each of these might have embedded metadata, using XML/RDF or
>some other older encoding. Using metadata= doesn't help here; instead we
>want to figure out how to extract data from each of these formats, either
>(?ideally) server side, otherwise, clientside or via some 3rd party
>service. Eg. media file URI is http://purl.org/net/danbri/bigpicture.jpeg
>We could either download the JPEG, and look inside for metadata. Or we
>could pass a reference to it to some specialised RDF Description Service,
>(which might return us an rdf/xml description of that object). Or else we
>could ask the server itself for metadata about that object, perhaps using
>content negotiation or WebDAV or HEAD.
>Longwinded point being that there's a world of possibilities and the
>'metadata=' syntactic suger addresses only a % of the scenarios that
>RDF-aware software systems will be grappling with...
Received on Wednesday, 17 November 1999 22:52:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:21 UTC