[whatwg] RDFa

[Kristof Zelechovski]

It seems to me identification and description of various entities is best
achieved with LDAP which is hierarchical by design.  Why wasn't LDAP adopted
for the purpose, given that it is older, widely used and well understood?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Brickley
Sent: Saturday, August 23, 2008 5:17 PM
To: whatwg at whatwg.org
Cc: Ben Adida; paul.miller at talis.com
Subject: Re: [whatwg] RDFa

DC.creator.corporateName.1
	Canterbury Archaeological Trust

DC.creator.phone.1
	+44 227 462062


DC.creator.personalName.2
	Paul Miller

DC.creator.affiliation.2
	Archaeology Data Service

...this expresses name, affiliation and contact information for a number 
of contributors to a work. Another example describes several 
contributors along with their roles (actor, director, etc). Again the 
attribute/value representations contained numeric indexes 
('DC.creator.role.9') to disambiguate which individual was being described.


[snip]


Actually we can do a fair bit more than simply have human readable 
strings. For example from the CC case, we've got a sub-property 
relationship between cc:license and dc:license. RDF often (more often, 
even) has relationships amongst classes too, and between classes and 
properties. So for example, the SIOC vocabulary defines a class 
sioc:User as a subclass of foaf:OnlineAccount; this is mechanically 
evident from http://rdfs.org/sioc/ns#    .... similarly, 
http://trac.usefulinc.com/doap defines the DOAP vocabulary, schema here 
- http://usefulinc.com/ns/doap# (webserver misconfigured re mimetype 
right now). DOAP defines a class doap:Project that subclasses FOAF's 
'Project' class, and which comes with a number of properties describing 
opensource software projects. Again this is mechanically evident. As the 
ccREL paper explains, and I can confirm w.r.t. FOAF, it is very useful 
to allow related projects to define related classes and properties but 
manage their evolution separately. It's a strategy for making 
incremental progress without a single project/organization carrying the 
burden of total coordination. Edd and friends in the DOAP project, for 
example, can keep developing new properties for describing projects. 
Elsewhere in the Web, we can be annotating the URI for 'foaf:Project' 
eg. with translations.