- From: Reto Bachmann-Gmuer <reto@gmuer.ch>
- Date: Tue, 11 Mar 2003 19:04:59 +0100
- To: Charles McCathieNevile <charles@w3.org>
- Cc: Brent Hendricks <brentmh@ece.rice.edu>, <www-annotation@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luned́, 10 Mar 2003, alle 16:51 Europe/Paris, Charles McCathieNevile ha scritto: > On Thu, 6 Mar 2003, Brent Hendricks wrote: > >> Charles McCathieNevile wrote: >> >>> For example I might want to claim that the creator of document is >>> <foaf:Person> <foaf:mbox> <mailto:charles@sidar.org> . >>> i.e. the person who has the email address charles@sidar.org, >>> expressed in >>> a way that can be processed by RDF and matched less ambiguously than >>> just a >>> literal. This is legal according to my reading of the schemas. >> >> It may be legal, but I'm not convinced that it's a good idea. If you >> create an annotation with some arbitrary RDF resource(s) as the value >> of >> dc:creator, there will be several Annotea clients that won't know what >> to do with it. > > In theory this means they are not correctly implementing what is > specified - > in general there is no reason in RDF not to do this. Not sure if I understand you right, if a resource is accepted as author, this mean that this resource can be of any type, even those that will be defined in future. How could a client possibly implement the protocol correctly? (Telling the user "you need a plugin to support visualisation of http://xmlns.com/foaf/0.1/" ?) > (...)It would be > good to know which annotea clients can or can't handle this kind of > thing > (and servers for that matter). Maybe it would be a useful extension of the protocol if clients could tell the server which rdf-schemas they support (similarly ore as a enhancement to the "accept" header in http), a smart server would then accept and store foaf:Person resource as author and deliver a literal to a client that does not indicate to know about foaf. What do you think? cheers, reto -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (Darwin) iD8DBQE+biVSD1pReGFYfq4RAlSkAKCQzlL1IOt3MfNBMvvBo/IZew1gXQCgpOQ8 84gHGeZubNXuSBAPcqIpfsg= =x1NL -----END PGP SIGNATURE-----
Received on Tuesday, 11 March 2003 13:09:15 UTC