- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 10 Mar 2003 10:51:31 -0500 (EST)
- To: Brent Hendricks <brentmh@ece.rice.edu>
- cc: Reto Bachmann-Gmuer <reto@gmuer.ch>, <www-annotation@w3.org>
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. Of course, as you say, that doesn't automatically mean that people will implement it. It would be good to know which annotea clients can or can't handle this kind of thing (and servers for that matter). I assumed in developing my little tools that this would be a possiblity, but they don't do anything useful yet where it would be an issue. I would prefer that it was specified that implementations should be able to cope with this approach, so people could say that their implementation was missing the capability but people could expect it in the future, or would realise that this is something to take into account in implementing. Another possibility is to explicitly specify that the content is a Literal, but i think there are use cases which show that isn't going to be as helpful in the long run. A third possibility is to have two vocabularies, where one is a subset that requires a Literal and the other allows for general RDF content - if this route is chosen I think that the choice of whether the existing schema should be one with explicit restrictions or should be the "full" one can depend on what works best for current implementors (but this is just my opinion - there may be other good reasons for going one way or the other that I haven't figured out yet). I think that this is like your proposal for profiles... just my 2 cents worth chaals
Received on Monday, 10 March 2003 11:05:35 UTC