- From: Laurian Gridinoc <laurian@gmail.com>
- Date: Mon, 20 Dec 2004 17:09:00 +0200
- To: Dom Vonarburg <dom@rorweb.com>
- Cc: www-rdf-interest@w3.org
Hello, On Mon, 20 Dec 2004 09:31:10 -0500, Dom Vonarburg <dom@rorweb.com> wrote: > > Anyway, I've taken a quick peek at your spec and one thing strikes me > > as odd; why do you define the type of the described resources as a > > literal? Why not make the those classes (like SiteMap, Menu, Contact, > > etc) _real_ rdfs classes, and define the type using rdf:type? > > > I see you mention the type literal being similar to rdf:type and seem > > to support both, but why not just use rdf:type? Also, how does the spec > > cope with rdf:lang in type literals? > > The reason for this is simple: to lower the RDF learning curve. ROR is an > XML and RDF/XML vocabulary. It is designed to be very easy to use by non-RDF > people, while still providing all the benefits of RDF (and RDF vocabularies) > to those who are comfortable with it. As people start experimenting with RDF > through ROR, they will soon appreciate the power of RDF and want to add > other vocabularies to their ROR documents. > > The type property will not support rdf:lang, since it does not represent a > descriptive aspect of the resource. Only defined class names can be used in > the type property (e.g. Main, Product, SiteMap, etc). I'll bring into discussion the Jon Hanna's resource/representation vocabulary draft [1], which seems closer to the developer point of view. Beside composition (similar with dc:hasPart, ror:resource) it has also criteria for selecting alternative representations. It would be nice to have in ROR at least alternative representations and criteria. [1] http://www.hackcraft.net/rep/rep.xml Cheers, -- Laurian Gridinoc Chief Developer GRAPEFRUIT www.grapefruit.ro
Received on Monday, 20 December 2004 15:09:04 UTC