Re: @about/@instanceof discussion

Ivan Herman wrote:
> Manu Sporny wrote:
>> 1. @about       [Set the Subject]
>> 2. @instanceof  [Set the Subject Type]
>> 3. @rel/@rev    [Set the Predicate]
>> 4. @property    [Set the Predicate]
>> 5. @resource    [Set the Object or Subject if there is no active @about]
>> 6. @href        [Set the Object]
>> 7. @src         [Set the Object]
>> 8. @content     [Set the Object]
>> 9. @datatype    [Set the Object Data Type]
>>
> 
> Manu, why would you make a difference between @resource and @href?

Because I don't know what I'm doing! :)

Apologies - I thought that there was a slight difference between them,
thanks for correcting me. The corrected rules above should read:

1. @about       [Set the Subject]
2. @instanceof  [Set the Subject Type]
3. @rel/@rev    [Set the Predicate]
4. @property    [Set the Predicate]
5. @resource    [Set the Object or Subject if there is no active @about]
6. @href        [Set the Object or Subject if there is no active @about]
7. @src         [Set the Object]
8. @content     [Set the Object]
9. @datatype    [Set the Object Data Type]

> For my understanding: if I put this issue of @resource aside, the only
> difference between what we have now and what you propose is that
> @instanceof applies to the subject no matter where it comes from (either
> from an explicit @about or inherited from the parent). Is that correct?

Yes, I think so... unfortunately, I tend to get confused about the
nuances in the current processing rules. I'm waiting for somebody to
correct me on the rules above... :)

I'm attempting to do 3 things with the approach listed above:

 - Summarize the set of rules that we have currently.
 - Propose how we handle @instanceof.
 - Create something that is very easy for publishers to understand.

In hindsight, it would probably be good to focus on one of those at a time.

Ben, Ralph and I had a very good discussion yesterday where Ben
explained his approach in much more depth. I was able to finally grok
Ben's approach at a high level and we all came to some understanding on
several issues:

1. It doesn't really matter what the processing rules are, as long as
   they are simple for publishers to understand AND they make
   logical sense when combining attributes.
2. Regular web publishers are probably going to rely more on tools to
   tell them if their RDF is correct than understanding the edge-case
   processing rules. So, having complicated edge-case processing rules
   isn't as bad as I'd like to believe it is :)
3. Long-term adoption of RDFa will have to do more with the tools that
   are available to write RDFa than what the processing rules are.
   Short-term adoption of RDFa will have to do more with the
   processing rules because the RDF community will probably be the first
   to comment on it and create tools for it.
4. The processing rules must make logical sense as you add more RDFa
   attributes to an element. When you're doing things that are additive,
   such as adding @instanceof or @about to an element, the resulting
   triples shouldn't change dramatically.
5. Both Ben or my approach should work with the currently approved
   test cases.

With those four points - it should give us a good approach at picking a
final solution. Ben said that he would summarize his rules and post them
to the list as he asserts that they are fairly easy to understand. In
that e-mail, he'll demonstrate how adding RDFa attributes to an element
supports the most common use cases and has a logical progression.

I'm hoping that the rules I've outlined above will fall apart given the
set of use cases that Ben has identified, and we'll have a clear choice
in the end.

Mark, is your model different than the one I have proposed above?

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk Launches World's First Open Music Recommendation Service
http://blog.digitalbazaar.com/2007/09/09/bitmunk-music-recommendation/

Received on Friday, 2 November 2007 15:27:39 UTC