W3C home > Mailing lists > Public > public-vocabs@w3.org > April 2014

Re: working of schema.org/WebPage

From: Jarno van Driel <jarno@quantumspork.nl>
Date: Sun, 20 Apr 2014 20:38:33 +0200
Message-ID: <CAFQgrbZpiZSc_E5tq77jZYCKn-7C7DcAQukUT639fC_uUG+ugw@mail.gmail.com>
To: Dan Scott <dan@coffeecode.net>
Cc: Thad Guidry <thadguidry@gmail.com>, "Wallis,Richard" <Richard.Wallis@oclc.org>, Jocelyn Fournier <jocelyn.fournier@gmail.com>, Jason Douglas <jasondouglas@google.com>, "<public-vocabs@w3.org>" <public-vocabs@w3.org>
"Hmm. http://schema.org/mainContentOfPage says it accepts a WebPageElement,
not Text."
Oops! [sigh] believe or not, I actually re-read my post 500x times to see
if I didn't overlook anything. Of course I should have said WebPageElement
there. (That's a big part of what this thread is about: WebPage >
relationTo > WebPageElement > relationTo > WebPage)

"...might be of interest to you."
I've been trying to follow along with that thread as much as I can but I
find it difficult due to it's complexity. Now I just read the proposal and
it seems actually makes sense to me, so I was wondering, is this the final
draft?

And to pull in something from that proposal: @isPartOf and @hasPart.

Looking at the current proposal for adding a reverse mechanism to Microdata
(https://www.w3.org/wiki/WebSchemas/InverseProperties) and imagining it
gets accepted, would @hasPart still be needed? RDFa, MIcrodata and JSON-LD
all would be able to express the opposite of @isPartOf. Or should it stay
part of the proposal simply to make life easier for those who are looking
for a property like @hasPart and aren't aware of the existence of a reverse
mechanism?

Now I recall, you and Karen Coyle saying something about using @hasPart for
WebPageElements in a previous thread by Martin Hepp (
http://lists.w3.org/Archives/Public/public-vocabs/2014Jan/0091.html), and
like I said in that thread, I am quite ok with using @*Part* for this.
Makes perfect sense to me to do it like that.

But I don't hink having @mainContentOfPage bound to CreativeWork is enough.
Many sites describe a Product, Event, MedicalProcedure, etc, all types
which aren't part of CreativeWork, yet which are marked up because they are
the main entity of that page. After all most sites don't go any further
with their markup than that.

Having said that, the @*Part* properties together with changing the
expected value of @mainContentOfPage to Thing would resolve all technical
issues to being able to chain it all together. So I'm all up for that.

Only question I still got left though, is what would be the argument to
tell all the 'elves' in the world so they get convinced there's a purpose
to start marking up all web page elements on a page. Just being able to
mark up all page elements isn't a good enough reason to actually do it.

Now I have OCD when it comes to marking up elements, so I'll do it. But
what would convince the other 99.99999999999% of the world to do so as
well. What's in it for the 'elves' besides a lot more work?




On Sun, Apr 20, 2014 at 7:57 PM, Dan Scott <dan@coffeecode.net> wrote:

> On Sun, Apr 20, 2014 at 07:04:54PM +0200, Jarno van Driel wrote:
>
>> What I find confusing about WebPage (+ it's subclasses) and it's relation
>> to WebPageElement(s) (+ it's subClasses) is where does it fit into the
>> whole (literally)?
>>
>> What I understand about semantic techniques until thus far is that they're
>> a way to explain what a page is about, what entities it contains, what
>> their individual meaning is and what their relations are relative to each
>> other. All quite abstract concepts since they're supposed to describe
>> 'meaning'.
>>
>> Yet when I'm marking up a WebPage, including it's WebPageElement(s),
>> trying
>> to chain it all together, to me it seems like I'm describing the domtree.
>> Now one can argue that when I'm doing this I actually am defining the
>> relations between entities, but there's nothing abstract about it. The
>> only
>> thing it describes is the order of the DOM: a WebPage, its
>> WebPageElement(s) and the Things it/they contain.
>>
>
> <snip>
>
>
>  And to complicate things even further, not everything needed to chain
>> everything together, while expressing the right context, is available:
>>
>> 1] Being able to define the main (or a collection of) entity of a WebPage.
>> @mainContentOfPage only accepts a text value??? (I agree with Jason;'s:
>> "Let's fix it!")
>>
>
> Hmm. http://schema.org/mainContentOfPage says it accepts a
> WebPageElement, not Text.
>
>
>  2] No clear properties are available to connect WebPageElements to a
>> WebPage. So far I have been using @mentions to connect Things together,
>> eg.
>> WebPage > mentions > WPSideBar, because there's nothing else for this. A
>> better property (eg. @child, @contains, @has, @part, @DOMElement) seems
>> missing to me since I'm describing the DOM and not a relation like: Guha >
>> colleagueOf > Dan.
>>
>
> The proposed domain and range changes of "isPartOf" (elevating it to
> CreativeWork, and enabling it to point at a CreativeWork) and the
> addition of "hasPart" in
> https://www.w3.org/wiki/WebSchemas/Periodicals,_Articles_and_Multi-volume_
> Works#Type:_CreativeWork
> might be of interest to you.
>
> (And hey, if you want to go and +1 that proposal so it can become an
> official thing, the pertinent thread is at:
> http://lists.w3.org/Archives/Public/public-vocabs/2014Apr/0058.html )
>
> Dan
>
Received on Sunday, 20 April 2014 18:39:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:39 UTC