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: Ivan Herman <ivan@w3.org>
Date: Fri, 12 Mar 2010 11:24:15 +0100
Message-ID: <4B9A164F.2010006@w3.org>
To: Toby Inkster <tai@g5n.co.uk>
CC: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Hi Toby,

general question: do you have somewhere a writeup of what is the
mechanism you have in mind? Because, frankly, I do not really understand
how your fallback would exactly work.

In general, I find the issue of a missing link compelling but I am not
100% sure that we should go down the line of making fallback
specification. I am just concerned about the possibly high cost of
specifications that would require...

As for the several vocabulary question below:

On 2010-3-11 20:47 , Toby Inkster wrote:
[skip]
> 
> 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]" />
> 	  </div>
> 	</div>
> 
> Let's assume that profile 'a' defines 'Foo' and 'bar'; and profile 'b'
> defines 'bar' and 'baz'.
> 

My model has always been the same as, say, the usage of xmlns. This is
also in line with the way the processing model works today, by having a
local copy of the uri mappings that is pushed down to the children of a
specific node.

> 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;

That is certainly my preferred approach

> 	- 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.
> 

That is my preferred approach

Copying the processing steps of the current document what I see happening is

- for the top level div, profile 'a' will generate a number of mappings,
ie, for 'Foo' and 'bar'
- when going to the intermediate div, that node will first inherit the
mapping from the top level, then interprets 'b' by essentially
overriding the definition of 'bar', and adding a definition of 'baz'
- span inherits the mappings of its parent, does not modify it because
there is no 'profile', and resolves the URI-s

This is similar to the way xmlns attributes are treated...

My 2 cents...

Ivan

> 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:
> 
> 	<http://example.com/vocab#Person>
> 
> is equivalent to this one:
> 
> 	<http://xmlns.com/foaf/0.1/Person>
> 


-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf



Received on Friday, 12 March 2010 10:23:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:06 GMT