For those of you who have been following Drupal 7 core development, you might be aware that many RDF patches have already been committed. So, before it's old news: Drupal 7 will ship with RDFa enabled by default on nodes, comments, terms and users!
The first alpha release of Drupal 7 will be created next Friday Jan 15th. We've already incorporated most of the feedback we received from the semweb community so far, but I wanted to give the community a last chance to review the RDFa markup and the default RDF mappings we use before it's too late. I should emphasize that all the markup and default RDF mappings that we ship in core will be pretty much set in stone after the stable release of Drupal 7, hence this call for feedback. Site administrators who care about semantics will be able to alter these mappings by installing extra modules, but many people (read several 10K sites) will just install Drupal 7 and not care about the semantics it generates. Therefore we want to make sure the RDFa generated by Drupal out of the box is somewhat correct and does not make folks from the semantic/pedantic web community angry :) - we've tried to keep the semantics as generic as possible for that reason.
RDF mappings
I've created a diagram representing the default semantics of the core data structure which has been committed and I would appreciate feedback on the RDF terms we've used.
RDFa markup
To make the RDFa markup review process easier, I've updated the usual testing site at http://drupalrdf.openspring.net/. It features a blog post with some comments which represents a typical Drupal 7 page annotated with RDFa. Some other pages have been randomly generated to be able to test the tracker which acts as a very simple sitemap in RDFa.
Note that the URI for the resources of type node, comment, term and user is the URI of the page which describe them. This has been decided in order to keep things simpler and after careful discussion with some members of the community. Hash URIs for identifying things different from the page describing them can be implemented quite easily but this case hasn't emerged in core (but will do in the modules people will build and use).
For those willing to try out the software by themselves, I've uploaded an unstable version of Drupal 7 core you can download which includes some of the last RDF patches which are still under review. Please file any bug you encounter at http://drupal.org/node/add/project-issue/drupal or leave a comment below.
Comments
Great work!
Thanks for your great work and the nice summary!
As you know I'm no expert with RDF so I didn't know sioc:User refers to an account only, not to the person holding the account. (see http://www.w3.org/Submission/sioc-spec/#sioc_User) That matches perfectly to an user account of drupal, however I think it might make sense to introduce an URI for the person holding the account in core. Doing so modules would have a resource they can use for specifying info about this person. Without that contribs might introduce even multiple persons for an account or worse they might add properties in the range of a foaf:person to the user account.
I could also go and introduce the person resource in profile2 and hope other will use it, but I think the place for it is in core. Also, what if contrib-X would refer to the resource for the person specified by profile2, no one would state the relationship of the person to its user account if profile2 isn't there.
Good point. This issue
Good point. This issue doesn't only occur in the case of users but anytime you are talking about a real life thing (ie foaf:Person) vs the page that describes that thing.
The URI for the sioc:User is the node URI, which conceptually means that the page and the user are the same thing. This is in keeping with the discussions of the SIOC Working Group.
Using the node URI for the sioc:User leaves the hash URI (user/id#this) available for the actual foaf:Person associated with that user, so profile2 can use the hash URI.
Dual profiles
If a real person has several accounts on the same site, you can state
</user/2#me> owl:sameAs </user/45#me>.(#me or #this is just a convention to choose and agree on). Don't forget to also link the foaf:Person to their sioc:User with:
</user/2> sioc:account_of </user/2#me>.</user/45> sioc:account_of </user/45#me>.
# optional
</user/2#me> rdf:type foaf:Person.
</user/45#me> rdf:type foaf:Person.
We left this out of core since there was no real use case (in core) which required it and can be easily added by contrib modules.
Standardisation?
I think you didn't understand me right.
I see that it isn't hard to implement it in contrib, but my actual point is the lack of standardisation. Modules have to agree on a common URI for the person or we will end up with modules inventing different persons for the same user account.
If your suggestion to assign
If your suggestion to assign a foaf:Person URI for each sioc:User, feel free to create a feature request for core, though it might be too late the alpha coming out tomorrow. Either way, there isn't much to standardized here, since all you have to do it add #me to the profile URI to get the person URI. (I would leave
#thisfor more generic resources which are linked to their foaf:Document via foaf:primaryTopic). If this does not go in core, it could easily go into the rdf module in contrib. Did you also mean to implement hook_user_load and add it to the user object? This is something that we'll definitely do in rdf contrib.See issue for Drupal 7
@fago: I changed my mind on this, see Associate a standardized foaf:Person URI to each user profile
kudos
Hi
I am a newbie in Drupal but have been following the SemWeb for some years. I read some months ago of RDF Drupal but I wasn't much interested in the CMSs at that time. A mail in the foaf-dev mailing list about this last call reminded me of RDF Drupal so I have read scor's et al. 'Produce and consume linked data with Drupal' and think that this is a key point in the adoption of SW technologies. Very good work! That said, the RDF mapping seems ok to me.
use case for person URI in user
Another use case might be if one wanted to aggregate or infer information from nodes, comments from multiple Drupal sites and you wanted to know if the same person provided the content in those nodes, comments.
I'm not sure if this is a use-case for Drupal core or not.
skos:Collection
I'm not sure that you really want to use skos:Collection.
SKOS collections are used to represent "arrays" in thesaurus terminology.
I think you want to indicate that concepts belong to a vocabulary, a thesaurus:
SKOS offers the means of representing such vocabularies, thesauri using the skos:ConceptScheme class.
Paul
patch
Thanks PaulZH for this very good feedback! It would be great if you could review the patch for this fix, see also the related discussion on the SKOS mailing lists.