W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: ISSUE-1: What happens when you can't dereference a profile document?

From: Toby Inkster <tai@g5n.co.uk>
Date: Thu, 11 Mar 2010 19:47:18 +0000
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: RDFa WG <public-rdfa-wg@w3.org>
Message-ID: <1268336838.15904.44.camel@ophelia2.g5n.co.uk>
On Thu, 2010-03-11 at 12:37 -0500, Manu Sporny wrote:
> Both Ben and Toby have been concerned about what happens when you
> cannot dereference an RDFa Profile document. Both of them have
> expressed that he would like to see a placeholder triple that is
> generated when a profile document cannot be dereferenced. RDFa
> toolchains can then dereference the profile document at a later time
> and re-write the triple when the profile document becomes available. 

Frankly it's not just the case of what happens if the profile document
is temporarily down, but we also have to consider what happens if the
profile document is *permanently* down.

Let's assume that this:

	<b profile="http://example.com/vocab" typeof="Person"
		property="name">Joe Bloggs</b>

Is supposed to expand to:

	@prefix foaf: <http://xmlns.com/foaf/0.1/> .
	[] a foaf:Person ; foaf:name "Joe Bloggs" .

But the example.com vocabulary disappears *permanently*. Now say we
allow it to continue to generate triples, using fallback URIs, e.g.

	@prefix vocab1: <http://example.com/vocab#> .
	[] a vocab1:Person ; vocab1:name "Joe Bloggs" .

Now, tools that know about FOAF won't know what these triples mean, so
you might wonder what's the value in them. But when we start to combine
them with triples found on other pages, the value starts to appear.

Say another page contains:

	<b profile="http://example.com/vocab" typeof="Person"
		property="name">Alice Gibbs</b>

Then our theoretical consumer knows that Joe Bloggs and Alice Gibbs are
the same kind of thing, in some way.

A third page might contain:

	<div xmlns:foaf="http://xmlns.com/foaf/0.1/"
	  profile="http://example.com/vocab" typeof="Person">
		<span property="name">Bob Jenkins</span>
		(<span property="foaf:gender">male</span>)

Now, not only does it know that Bob Jenkins is the same type of thing
that Alice Gibbs and Joe Bloggs are; it also knows that Bob Jenkins is a
foaf:Agent (this can be reasoned from FOAF's definition of the
foaf:gender property). It can't be sure that Alice Gibbs and Joe Bloggs
are foaf:Agents, but it can be sure that this vocab1:Person class isn't
disjoint with foaf:Agent. (i.e. they're at least overlapping classes.)

That is, making the parser generate fallback triples allows the consumer
the option of building up a picture of the profile terms from other
sources, regardless of whether the profile eventually becomes available

A big question that needs to be answered before we can determine whether
this is feasible is: how many profiles can be active at once?

e.g. given:

	<div profile="a">
	  <div profile="b">
	    <span typeof="Foo" property="bar" resource="[baz]" />

Let's assume that profile 'a' defines 'Foo' and 'bar'; and profile 'b'
defines 'bar' and 'baz'.

For 'baz', I don't imagine there is any contention. Profile b's
definition wins.

For 'bar' there are three possible outcomes:

	- it resolves to profile b's definition only, as the nearest
	  ancestor profile;
	- it resolves to profile a's definition only, because it "got
	  there first"; or
	- it generates two triples, using both definitions.

But what about 'Foo':

	- it's treated as typeof="" because the nearest ancestor
	  profile does not define it; or
	- the parser figures out that b does not define Foo, so
	  checks the next ancestor profile for a definition.

If we make the decision that there's only ever one profile active, then
when parsing the <span/>, profile 'a' will be ignored, so we get 'Foo'
undefined, with 'bar' and 'baz' defined by profile 'b'.

If there's only every one profile active, then generating these fallback
triples becomes a very easy option, because we know exactly which
profile was *supposed* to define them.

> Toby has an alternate mechanism that uses @default-prefix and requires
> RDFa processors to understand a subset of OWL.

@default-prefix was just a temporary name for the attribute while we
were deciding. @profile is fine.

The subset of OWL required is not much more complicated to implement
than the current suggested vocabulary for profiles. It's merely a way of
saying that this term from the profile:


is equivalent to this one:


Toby A Inkster
Received on Thursday, 11 March 2010 19:48:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:17 UTC