The Deferred Resolution Graph (was: Re: A new approach to accomplishing RDFa Profiles)

On 03/20/2010 06:07 AM, Ivan Herman wrote:
> But then we are discussing three proposals, aren't we?

Not necessarily... more below.

> On 2010-3-19 21:31 , Manu Sporny wrote:
> [skip]
>>
>> * RDFa vocabulary proposal (Ivan/Manu)
>> * @token proposal (Mark)
>> * Default prefix proposal (Toby/Martin)

We could reconcile the RDFa vocabulary proposal and the default prefix
proposal by doing this:

<p profile="http://example.com/my-vocab#"
   about="#curious-character" typeof="Book">
   <span property="title">Surely You're Joking, Mr. Feynman!</title>
</p>

The example above mixes the Bibliography (Book) and Dublin Core (title)
ontologies. There are two cases that we're interested in:

1. What happens when you can dereference the @profile?
2. What happens when you can't dereference the @profile?

What happens when you can dereference the @profile
--------------------------------------------------

This is the easiest and most straight-forward case. If you can
dereference the @profile, assuming error-free profile and author
documents, you will have the set of mappings and thus can generate the
proper RDF triples *in the default graph*:

<#curious-character>
   rdf:type
      bibo:Book .

<#curious-character>
   dc:title
      "Surely You're Joking, Mr. Feynman!" .

I don't think anybody would argue that this is ideally what we want to
happen. This always works as long as the @profile document is available
(via ad-hoc download, via an application ontology cache, via a ontology
backup service, or if the @profile document triples are hardcoded in the
parser).

What happens when you cannot dereference the @profile
-----------------------------------------------------

This is the case that the default prefix approach excels at addressing.
At this point, let's introduce a completely new concept called the
"Deferred Resolution Graph" (DRG). This graph is where triples that
cannot be resolved, due to @profile document dereferencing issues, are
placed until the @profile document that they depend on can be retrieved.

Let's assume that @profile has the added semantics of @vocab as Toby has
defined in this e-mail:

http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0174.html

Therefore, the following markup:

<p profile="http://example.com/my-vocab#"
   about="#curious-character" typeof="Book">
   <span property="title">Surely You're Joking, Mr. Feynman!</title>
</p>

would produce the following triples, if the @profile document can be
retrieved, *into the default graph*:

<#curious-character>
   rdf:type
      bibo:Book .

<#curious-character>
   dc:title
      "Surely You're Joking, Mr. Feynman!" .

If the @profile document *cannot* be retrieved, the following triples
would go *into the deferred resolution graph*:

<#curious-character>
   rdf:type
      <http://example.com/my-vocab#Book>^^UNRESOLVED .

<#curious-character>
   <http://example.com/my-vocab#title>^^UNRESOLVED
      "Surely You're Joking, Mr. Feynman!" .

Those triples in the *deferred resolution graph* could only be placed
into the *default graph* once the UNRESOLVED URIs are resolved at some
point (via ad-hoc download at a different time, via an application
ontology cache, or via an ontology backup service).

Conclusion
----------

So Ivan, while you stated that we are talking about three different
proposals, I hope that this demonstrates that the RDFa vocabulary
proposal and the default prefix proposal can be combined with relative
ease to produce a hybrid approach that produces the benefits of both
approaches.

Note that while I took the time to outline the possible deferred
resolution graph concept, I think it's a bad idea for a number of reasons.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Sunday, 21 March 2010 16:40:14 UTC