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

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