[whatwg] RDFa
Kristof Zelechovski
giecrilj at stegny.2a.pl
Sat Aug 23 08:47:01 PDT 2008
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.
More information about the whatwg
mailing list