Drupal 7 core already supports disambiguation of the user account and the person information resource in the user profile page. However this is hard coded, and we should support this for all entity types by extending core's RDF mappings API. I'm thinking that at least we should allow each entity instance to have an information resource associated with it (i.e. a node and its information resource as #this linked to each other with foaf:primaryTopic). We need a way to get a given field out of the way if it's not meant to be used by the core API, I'm thinking we can simply append #fragment to its field name. Some RDF mappings examples.

Birthday for a person:

        'field_birthday#me' => array(
          'predicates' => array('foaf:birthday'),
          'callback' => 'date_birthday',
          'resource' => 'me',     
        ),

A car and its make:

        'rdftype#this' => array('car:Car'),
        'field_make#this' => array(
          'predicates' => array('car:make'),
          'type' => 'rel',
        ),

The field_name#fragment is kind of ugly but that's the only way I can think of to avoid a field being output by core in RDFa. These mappings above are likely to be generated by the RDF mapping UI anyways and exported via features/Entity API, so they should be easier to deal with.

Another alternative is to insert an extra level of nesting with the fragment like this:

      'mapping' => array(
        'rdftype' => array('sioc:Item', 'foaf:Document'),
        'title' => array(
          'predicates' => array('dc:title'),
        ),
        'created' => array(
          'predicates' => array('dc:date', 'dc:created'),
          'datatype' => 'xsd:dateTime',
          'callback' => 'date_iso8601',
        ),
        'body' => array(
          'predicates' => array('content:encoded'),
        ),
        // so far the above is just like the core RDF mappings structure.
        // below are the information resources mappings.
        '#this' => array(
          'rdftype' => array('car:Car'),
          'resource_name' => 'this',
          'predicates' => array('foaf:isPrimaryTopicOf'),
          'field_make' => array(
            'predicates' => array('car:make'),
            'type' => 'rel',
          ),
        ),

The first structure is field centric, the second is resource centric. I think I like the second form better. One thing I dislike is the use of # for naming resources because this is used in various APIs in Drupal, and not generally used for referring to instance or field names.

Comments

Anonymous’s picture

Anonymous (not verified) commented

For a little history, here is the original issue where the two URIs became baked-in to core.

#701672: Associate a standardized foaf:Person URI to each user profile

Anonymous’s picture

Anonymous (not verified) commented

I definitely prefer the second. The first implies that there would be two mappings for each field, which in most cases would not be the case. In most cases, each field relates either to one resource orthe other.

How will this then be used in the RDFa? It would be tough to add it to RDFa itself because of the nesting structure. So would you think it should be handled as meta tags?

Anonymous’s picture

Anonymous (not verified) commented

I'm thinking maybe the most sustainable thing to do is to recommend that people use things like field_collection and profile2 to create the 'thing' and then have it loaded on the node about that thing. We could then give a checkbox or field for all entities that specifies whether it is a document resource or a thing resource.

For example, the Main Profile profile2 type could be a thing. The default for profile2 would be that it is a thing with the fragment 'me'.

This keeps the distinction between fields that are on the node and fields that are on the thing clearer and I think makes the mental model easier to grasp.

Anonymous’s picture

Anonymous (not verified) commented

I'm not sure that this will be possible to support.

The major problem is setting the resource attribute when the non-document resource is the object of a predicate... for instance, if we are on a page where there is a node reference to the non-document resource. We would have to insert a resource attribute on the a tag or on the surrounding li in order to get the correct URI in the object position. However, in Relation module this link is handled entirely through the formatter with no theme function. Since there is no theme function, there is no way to interject the resource attribute with preprocess.

Even if there was a theme function for relation, we would have to tightly couple the insertion of the resource attribute to the relation theme function. This would require a new implementation of the logic for each relation-type field formatter that was introduced as a contrib module. I don't think that this is a sustainable method within the community.

I know that I was a proponent of maintaining the distinction between document resources and non-document resources. However, I'm beginning to think there is no elegant way to do it in the system. Also, it is a conceptual distinction that would be difficult to communicate to Drupal users anyways.

Should we consider abandoning the effort to follow the Cool URIs for the Semantic Web Note? This would mean that we do not distinguish between documents and non-documents and return 200 OK for both kinds of resources.

scor’s picture

scor commented
Project: Resource Description Framework (RDF) » RDF Extensions
Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed

This draft document that came out of the recent W3C TAG face to face is relevant: http://www.w3.org/2001/tag/awwsw/issue57/20110625/

I'm going to postpone this until the httprange14 discussion has been resolved.