Re: Discussion draft: RDF Description Services

Hi Jonas

Thanks for the comments; replies intersperced below

On Sun, 5 Dec 1999, Jonas Liljegren wrote:
> Dan Brickley wrote:
> > 
> >         RDF Description Services
> >         Current Version: http://www.w3.org/1999/11/02-RDFServices/
> > 
> > 
> > The intention is to define something _extremely_ simple. Basic idea is
> > that an RDF Description Service can be exposed via http to allow queries such
> > as  http://fiction.w3.org/metabureau?{some_URI}
> 
> The PICS functionality almost come by itself from the RDF spec. This
> is almost self evident, but I could make some comments.

Yes, The Model, Syntax and Schema components of RDF already duplicate most
of PICS. The 'Description Service' proposal is intended to help complete
the transition. In addition, the XML Signatures work will replace signed
PICS labels, and (hopefully) the work items being discussed informally
here (RDF IG) will ultimately lead to an RDF Rules language that will
emcompass both PICS Rules (for specifying preferences over PICS
content) and the 'rdf:aboutEachPrefix' adhoccery
from RDF Syntax which currently serves as a placeholder for 'generic'
(multi-resource) labels.

RDF Description Services are IMHO both 'low hanging fruit'
w.r.t. the PICS-to-RDF transistion and fun things to explore building and
federating into interlinked services.



> The method of using one base URL for providing meta data about URIs
> with another base is intresting.


there are a bunch of ways this could've been approached; I picked a simple
one.

The context for this is...

	PICS Label Distribution Label Syntax and Communication Protocols 
	http://www.w3.org/TR/REC-PICS-labels#Requesting
		Requesting Labels Separately 


	PICS labels can also be retrieved separately from the documents to which
	they refer. To
	request labels in this way, a client contacts a label bureau. A label
	bureau is an HTTP server
	that understands a particular query syntax, defined below. It can provide
	labels for
	documents that reside on other servers, and, indeed, for documents
	available through
	protocols other than HTTP. It is anticipated that there will be
	"well-known" label bureaus
	which dispense (possibly for a fee) labels created by many rating
	services. 


If you look at the examples in this PICS spec, which is the current W3C
Reccomendation for metadata bureaus, you'll see it is slightly more
complex than the dumb protocol I propose. 


> The other method would be to use the URI itself as an URL to give
> metadata about the thing denoted by the URI.

While in a lot of cases it'll be possible to do this sort of thing, the
Description Services doc was really targetted at cases where descriptions
may need to be offered by 3rd parties.

Often, applications will want a third-party's opinion on a
resource. Product reviews, movie reviews (imagine a machine-understandable
version of http://www.capalert.com/ ), annotations,
automated summaries and classifications, shared bookmark comments and
categories, privacy, child-protection or health warnings... There are
countless scenarios where the resource owners voice will usefully be
weighed against those of others.


> There is always the problem of knowing if the URI is the content of
> the URL or something else. It could be a good thing to not use the
> URL as a way to give metadata about the URI.

HTTP HEAD is sometimes useful for this; also content-negotiation and
WebDAV have roles here.



> But you would like to know where to get more information about a
> specific URI. That could maby be the job for a couple of
> meta-metabureaus. That is, to give a list of see-also to other
> description services.

Yes, this is a particular concern of mine that I tried to leave as mostly
out-of-scope for this proposal. In the general case, annotation discovery
is a tough problem. There are a few mechanisms that can be used in
combination; Peter Valkenburg and I tried to sketch some possibilities in
a position paper for W3C's QL'98 workshop last december,
http://www.w3.org/TandS/QL/QL98/pp/distributed.html if you're interested.

With seeAlso references, we have a mechanism for exposing
forward-knowledge amongst description services without specifying anything
about how those servers come to have such knowledge. This seems to me to
be a nicely modular approach; sometimes a server might have mass 'bulk
metadata' about anothers' contents; other times it might have higher level
declarative knowledge and heuristics that might lead to similar
conclusions about other relevant servers-to-ask. But the Description
Services doc doesn't need to enumerate these mechanisms; that's left for
perl hackers, prolog hackers and the marketplace to decide...

In passing, the notion of meta-metabureaus that act as hubs or index
servers is similar to the query routing and forward knowledge mechanisms
used in WHOIS++ and CIP (mostly for white pages data) -- see for eg. refs in
http://www.dlib.org/dlib/january98/01kirriemuir.html


> 
> * Attribution
> 
> Shouldn't this be coupled with the XML signature work?
> 	http://www.w3.org/Signature/

Certainly. There are various granularities at which we might want such
attributions: per RDF statement, per server ('all opinions here come from
PhDs in Medicine') etc... 

On the less-is-more front again, I think it is possible to specify an
implementable RDF Description Services doc without tightly binding it to
one strategy for managing attributions and trust. The RDF document
returned means whatever the data inside it means; if that includes XML
Signature constructs so much the better.



> * Protocol Interfaces
> 
> I don't think that using HTTP presents any problems. The applications
> using RDF Services should handle HTTP as well as RDF/xml.

I glossed over some detail on this. I'm keen to decouple the abstract
notion of an RDF Description Service from particular protocols.

(hmm -- how does WAP and mobile access fit in here? eg. a mobile phone
wanting to ask about some geographical resource...)


> The error messages would have the same meaning.

Yes; I don't see need for anything extra

> Content negotiation could be used to request the document to be in
> RDF/xml instead of the old PICS format. That would make it possible to
> use the same URL for both services.

I think so

> Also: GET/HEAD should be handled the same. The HEAD request would be
> used to see if there is a new version of the answer, but would not
> give the answer.

Yep. (Reminds me to figure out how CGI scripts can implement HEAD.)

> 
> * The client interface
> 
> PICS talks about how to represent the metadata as a form. Some
> attributes could have a couple of possible values, for the rating of
> violent content, etc.
> 
> This would be done using RDF schemas?

RDF Schema provides some barebones mechanisms for this. I expect many
user-interfaces will be more tightly constrained in particular contexts,
ie. won't allow users to create all the RDF expressions that might be
allowed.

> I see the need for a description of a way to render a interface for
> some subset of schemas.

Data-creation interface or you mean general-purpose RDF
visualisation? In either case, I'd argue that this is a separable problem
from the metadata bureau problem...


Dan

Received on Sunday, 5 December 1999 23:22:33 UTC