Re: The processing rules for property/rel

Hi,

On Mon, Oct 31, 2011 at 6:41 PM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
> On Oct 31, 2011, at 8:23 AM, Ivan Herman wrote:
>
>> Just another, maybe even more heretic point:-)
>>
>> What would be the consequences if
>>
>> - we changed the behaviour of the @rel/@typeof combination the same way as you propose @property/@typeof? To keep the symmetry between the two...
>> - we restricted the whole change to @typeof only which has a peculiar behaviour anyway...
>
> If I could go back in time and influence behavior in RDFa 1.0, this is probably what I would have done. It might take a scan to determine (outside of <img> usage, which we've broken anyway) how much this would break. It's certainly a MAJOR change to existing behavior that has the potential to be very disruptive for legacy usage, but if we are more explicit about detecting RDFa 1.0 vs. 1.1 encodings, it may work.

I've taken a stroll down memory lane and looked at some of the emails
in the old "public-rdf-in-xhtml-tf" list [1] from mid-2007 to spring
2008. :)

Initially I think we had this behaviour on @typeof (then called
@instanceof; see e.g. [2]). It might be interesting (or painful) to
scan through those old conversations for thoughts and use cases. I did
also have problems with the turnout (having use cases like that
described in [3]).

So I'm very interested in investigating what we can do here. For the
record, I also agree with Gregg that @property, if changed as
proposed, should work with chaining. Maybe this can amend @typeof.
And/or maybe we can do something about the way @rel and @typeof
"disconnect" today...

A quick guess is that the cases where most RDFa attributes appear at
once on an element are rare to nonexistent. E.g. a  thing like:

    <img src="beast.jpg" rel="cc:licence" resource="/copyleft"
typeof="foaf:Image" property="rdfs:label" content="Beast" />

is probably hard to find in the wild... So maybe rules for how a
combination of different attributes will change how both
@href/@resource and @typeof are captured isn't beyond comprehension if
declared properly..

I'm not really sure though how @property, @resource and @typeof
together would behave in the new proposal? Would this:

    <div property="chapter" resource="#ch-1" typeof="Chapter">
        <h2 property="title">Chapter One</h2>

Give:

    <> :chapter <#ch-1> .
    <#ch-1> a :Chapter;
        :title "Chapter One" .

, or am I way off?

(Note that I'm still on the fence as to whether this new "smart"
property and its effects are valuable. And I figure that my use case
above might not be the most common.)

Anyway, this needs proper attention (and I'm done for the day).

Best regards,
Niklas

[1]: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/
[2]: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Sep/0169.html
[3]: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jan/0091.html



> Cleaner, I think, to make a clear break, and add the behavior to @property so that we avoid the confusion with @rel altogether, while introducing what I think is a lesser impact with existing @property usage.
>
> Gregg
>
>> Just musing before going home...
>>
>> Ivan
>>
>>
>>
>> On Oct 31, 2011, at 13:22 , Ivan Herman wrote:
>>
>>> Gregg,
>>>
>>> (I hope it is all right to involve the group here)
>>>
>>> I understand the motivation, looking at some of the microdata examples although. But I am also afraid a bit of the 'story', so to say, ie, how would you really present this as a consistent model on RDFa rather than looking as a spaghetti code...
>>>
>>> 1. Difference between @rel and @property. If we take the minimalist approach, there is a good deal of consistency in the story: they behave mostly identically, except for the fact that @property does not generate chaining. That would still be true in a setting like
>>>
>>> <a property="blah" href="Foo"><span property="bar">Something</span></a>
>>> <a rel="blah" href="Foo"><span property="bar">Something</span></a>
>>>
>>> The difference between the two being what the subject is for the (? <bar> "Something"): chaining or not chaining.
>>>
>>> 2. However, your extra change would also mean that
>>>
>>> <a property="blah" about="Foo"><span property="bar">Something</span></a>
>>> <a rel="blah" about"Foo"><span property="bar">Something</span></>
>>>
>>> would be radically different, right? The first one would generate
>>>
>>> <> <blah> <Foo> .
>>> <Foo> <bar> "Something" .
>>>
>>> whereas the second would say... nothing. Indeed there would be hanging rels of the form (<Foo> <blah> ?) and those are not resolved.
>>>
>>> Now this may mean that the behaviour defined for @rel is not optimal, but I do not believe we should go there and change that, too... But what we would have is a very different behaviour between the two; I would have difficulties to provide a clear picture/mental model on the differences. Maybe it is only me...
>>>
>>> So my question is: what kind of consistent picture can we give on what @property does and what @rel does? The situation in RDFa 1.0 is clear for RDF people: one generates a Literal object the other an IRI Resource object. The minimalist extension of the @property behaviour means that they usually behave the same way, except that @rel controls also chaining and it is also to be used for substructures. This is still fine. But what would one say if with a maximalist extension is adopted?
>>>
>>> Ivan
>>>
>>> P.S. B.t.w., just to have a clear understanding... the minimalist @property behaviour would indeed not change the mapping of
>>>
>>> [[[
>>> <div itemscope itemtype="http://schema.org/Event">
>>> <div itemprop="offers" itemscope itemtype="http://schema.org/AggregateOffer">
>>>  Priced from: <span itemprop="lowPrice">$35</span>
>>>  <span itemprop="offerCount">1938</span> tickets left
>>> </div>
>>> </div>
>>> ]]]
>>>
>>> its RDFa 1.1 expansion would be something like
>>>
>>> [[[
>>> <div typeof="http://schema.org/Event">
>>> <div rel="offers">
>>>   <div typeof="http:schema.org/AggregateOffer" >
>>>     Priced from: <span property="lowPrice">$35</span>
>>>     <span property="offerCount">1938</span> tickets left
>>>   </div>
>>> </div>
>>> </div>
>>> ]]]
>>>
>>> with the maximalist @property behaviour I believe what would be needed is:
>>>
>>> [[[
>>> <div typeof="http://schema.org/Event">
>>> <div property="offers" typeof="http://schema.org/AggregateOffer">
>>>  Priced from: <span property="lowPrice">$35</span>
>>>  <span property="offerCount">1938</span> tickets left
>>> </div>
>>> </div>
>>> ]]]
>>>
>>>
>>>
>>> On Oct 31, 2011, at 01:53 , Gregg Kellogg wrote:
>>>
>>>> On Oct 29, 2011, at 8:30 AM, Ivan Herman wrote:
>>>>
>>>>>
>>>>> On Oct 29, 2011, at 17:04 , Gregg Kellogg wrote:
>>>>>
>>>>>> On Oct 29, 2011, at 2:19 AM, "Ivan Herman" <ivan@w3.org> wrote:
>>>>>>
>>>>>>> I realized that your tests, both in this mail and on the wiki page, are based on the additional chaining behaviour you define for @property. SOrry about that, but at this moment I am still rather against that part of the changes, as I will explain in the answer to Ben's longer email...
>>>>>>
>>>>>> Only the last couple of tests involve chaining. I'd be fine if we left that part out. I'll separate them in my tests.
>>>>>>
>>>>>> What would the effect of @property with @typeof be? Would you expect @property to take on the literal value of the element? This would be the complete opposite if Microdata's behavior; wouldn't that be just a new source of errors?
>>>>>
>>>>> I do not know about microdata. But if I look at the RDFa structure, the consistent approach is that @typeof sets the subject just as it does anywhere else. If we changed that, this would be a complete mess: in most of the cases it sets the subject, and it is used as an object for @property...
>>>>
>>>> @typeof does set the subject, it just set's _new subject_. The affect of @property with @typeof is to create a relationship from _parent subject_ to _new subject_. If you look at most any schema.org example, it uses chaining using a similar rule:
>>>>
>>>> <div itemscope itemtype="http://schema.org/Event">
>>>> <a itemprop="url" href="nba-miami-philidelphia-game3.html">
>>>> NBA Eastern Conference First Round Playoff Tickets:
>>>> <span itemprop="name"> Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) </span>
>>>> </a>
>>>>
>>>> <meta itemprop="startDate" content="2016-04-21T20:00">
>>>>  Thu, 04/21/16
>>>>  8:00 p.m.
>>>>
>>>> <div itemprop="location" itemscope itemtype="http://schema.org/Place">
>>>>  <a itemprop="url" href="wells-fargo-center.html">
>>>>  Wells Fargo Center
>>>>  </a>
>>>>  <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
>>>>    <span itemprop="addressLocality">Philadelphia</span>,
>>>>    <span itemprop="addressRegion">PA</span>
>>>>  </div>
>>>> </div>
>>>>
>>>> <div itemprop="offers" itemscope itemtype="http://schema.org/AggregateOffer">
>>>>  Priced from: <span itemprop="lowPrice">$35</span>
>>>>  <span itemprop="offerCount">1938</span> tickets left
>>>> </div>
>>>> </div>
>>>>
>>>> Replace @itemprop with @property, remove @itemscope, and replace @itemtype with @typeof, and you pretty much have the proposed behavior. If you didn't do this, we'd need to add BNode identifiers where none were otherwise needed.
>>>>
>>>> Gregg
>>>>
>>>
>>>
>>> ----
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ----
>> 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
>>
>>
>>
>>
>>
>
>
>

Received on Monday, 31 October 2011 20:52:57 UTC