- From: Jarno van Driel <jarnovandriel@gmail.com>
- Date: Fri, 18 Apr 2014 16:39:50 +0200
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Larry Betts <lbetts@thoughtwm.com>, "Dr. Richard H. McCullough" <rhm@pioneerca.com>, Niklas Lindström <lindstream@gmail.com>, public-rdfa <public-rdfa@w3.org>
- Message-ID: <CADK2AU3Ubu2Rjr2pmLWWLaf6E-V=LKV0rO1NOmm3LM4vU9Wt6A@mail.gmail.com>
"Note that RDFa does not pass Alice..."
mmm. probable a copy paste error because when I ran it though RDFa play the
'creator' had both the value Alice as well as that it was linking to the
Person. Ran it through again and now it doesn't show Alice. Good to know
though there is no difference in the data that gets parsed.
"RDFa email does not get set"
Good eye, I had missed that one.
"The telephone example is odd..."
That's because of different reasons than semantics. On most sites I
maintain the @href contains a different value than the <span>. I follow ISO
standards for defining the email address and phone number on the @href so
when you activate them on mobile devices it automatically start your mail
app or starts to dial. So I have to include their human readable versions
in an extra span.
"Also, in both cases, you use #me..."
#me is in there because I copied it from Niklas's example. To be honest I
haven't got a clue yet as to when use # and when not, simply because I
haven't looked into it yet. I already was dancing around the table to
finally get this far. Because I'm finally starting to make sense of the
similarities between Microdata and RDFa not only my Microdata markup is
improving but have I also become interested again in trying to understand
RDFa (finally). So for now I'm enjoying the moment, even though I know I'm
not there yet. Much to learn still.
And be careful with what you make me understand, before you know it I'll be
asking about OWL as well. ;)
Thanks for all the help thoug: http://www.w3.org/TR/xhtml-rdfa-primer/ is
actually starting to make sense to me because of it.
Is there any sense in me trying to wrap my head around it's predecessor (
http://www.w3.org/2006/07/SWD/RDFa/primer/) as well or is it too oudated?
2014-04-18 2:31 GMT+02:00 Gregg Kellogg <gregg@greggkellogg.net>:
> On Apr 17, 2014, at 4:48 AM, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
>
> I think I've figured it out:
>
> RDFa:
> <div vocab="http://schema.org/" resource="/alice/posts/trouble_with_bob"
> typeof="WebPage">
> <h2 property="name">The trouble with Bob</h2>
> <h3 property="creator" resource="#me">Alice</h3>
> ...
>
> <div resource="#me" typeof="Person">
> <p>
> <span property="name">Alice Birpemswick</span>,
> Email: <a href="mailto:alice@example.com"><span itemprop="email">
> alice@example.com</span></a>,
> Phone: <a href="tel:+1-617-555-7332"><span property="telephone">+1
> 617.555.7332</span></a>
> </p>
> ...
> </div>
> </div>
>
> Microdata:
> <div itemid="/alice/posts/trouble_with_bob" itemscope itemtype="
> http://schema.org/WebPage">
> <h2 itemprop="name">The trouble with Bob</h2>
> <h3><link itemprop="creator" href="#me">Alice</h3>
> ...
>
> <div itemid="#me" itemscope itemtype="http://schema.org/Person">
> <p>
> <span itemprop="name">Alice Birpemswick</span>,
> Email: <a href="mailto:alice@example.com"><span itemprop="email">
> alice@example.com</span></a>,
> Phone: <a href="tel:+1-617-555-7332"><span itemprop="telephone">+1
> 617.555.7332</span></a>
> </p>
> ...
> </div>
> </div>
>
>
> It’s always worth distilling the markup to make sure you’re getting what
> you expect. The RDFa translates to the following:
>
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfa: <http://www.w3.org/ns/rdfa#> .
> @prefix schema: <http://schema.org/> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
> <> rdfa:usesVocabulary schema: .
>
> </alice/posts/trouble_with_bob> a schema:WebPage;
> schema:creator <#me>;
> schema:name "The trouble with Bob" .
>
> <tel:+1-617-555-7332> schema:telephone "+1 617.555.7332" .
>
> <#me> a schema:Person;
> schema:name "Alice Birpemswick” .
>
> Microdata generates the following:
>
> @prefix md: <http://www.w3.org/ns/md#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfa: <http://www.w3.org/ns/rdfa#> .
> @prefix schema: <http://schema.org/> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
> <> md:item (</alice/posts/trouble_with_bob> <#me>);
> rdfa:usesVocabulary schema: .
>
> </alice/posts/trouble_with_bob> a schema:WebPage;
> schema:creator (<#me>);
> schema:name "The trouble with Bob" .
>
> <#me> a schema:Person;
> schema:email "alice@example.com";
> schema:name "Alice Birpemswick";
> schema:telephone "+1 617.555.7332” .
>
> Differences:
> - RDFa: property="creator" passes the value 'Alice' as well as creating a
> triple (WebPage - creator - Person)
> - Microdata: itemprop="creator" passes no value and only creates a
> triple
>
>
> Note that RDFa does not pass Alice, as the value of the creator property
> comes from the @resource. Microdata gets much the same, except’s its in a
> list, likely due to the Microdata registry settings.
>
> - RDFa: This type of triple can be made by using @resource on any HTML
> element
> - Microdata: This type of triple can only be made when using <link> or
> <a> because there has to be a @href
>
>
> Yes, but note that there are some other unexpected things going on here.
>
> RDFa email does not get set, as you use @itemprop, where you probably
> intended @property.
>
> The telephone example is odd, as the <a> element set’s the subject from
> @href, which is used within the span; you need to take care that the
> subject remains what you expect.
>
> Also, in both cases, you use #me, which is fine, but it means it’s
> relative to the webpage URL, and not the id you set for the WebPage type.
>
> Conclusion:
> The meaning of @resource changes depending on the way it's used. In
> Microdata this requires different markup:
> property + @resource (no typeof) == property + @href
> @resource + typeof == @itemid + itemscope = itemtype
>
> Is this correct and/or did I miss anything?
>
>
> Actually, they’re both pretty much the same:
>
> @resource + @typeof == @itemid + @itemscope + @itemtype
> @property + @href = @itemprop + @itemid + @itemscope
> @property + @href + @typeof = @itemprop + @itemid + @itemscope + @itemtype.
>
> Gregg
>
> 2014-04-17 12:14 GMT+02:00 Jarno van Driel <jarnovandriel@gmail.com>:
>
>> Thanks for explaining the comparison between the two.
>>
>> *"RDFa behaves differently if the element contains both @resource and
>> @property"*
>> I won't ask you about this yet Gregg because I've got plenty of reading
>> to do still and want to see if I can figure out what's behind it myself.
>> But I'm going to keep it in the back of my head in case I don't.
>>
>>
>> 2014-04-17 1:16 GMT+02:00 Gregg Kellogg <gregg@greggkellogg.net>:
>>
>> On Apr 16, 2014, at 1:47 PM, Jarno van Driel <jarnovandriel@gmail.com>
>>> wrote:
>>>
>>> I wouldn't actually know. I just am starting to wrap my head around
>>> @resource, @rev and @rel. Haven't had time to look into @about as well.
>>> Maybe somebody else can say something more educated about that?
>>>
>>>
>>> @itemid is essentially the same as @resource; when interpreting
>>> Microdata as RDF, it sets the subject of the triples for that @itemscope.
>>> It must be used on the same element as @itemscope and @itemtype. If you
>>> also have @itemprop on that element, the identifier will be set as the
>>> object of a triple relating to a previous item using the specified property.
>>>
>>> RDFa behaves differently if the element contains both @resource and
>>> @property
>>>
>>> Gregg
>>>
>>> 2014-04-16 22:45 GMT+02:00 Larry Betts <lbetts@thoughtwm.com>:
>>>
>>>> That's some great information Jarno! Would "itemid" be an analog to the
>>>> RDFa "reference"/"about"?
>>>>
>>>> Regards,
>>>>
>>>> *Larry P. Betts*
>>>> Search Engine Marketing Specialist
>>>>
>>>> Thoughtwire Marketing LLC
>>>> PO BOX 8077
>>>> Mansfield, OH 44907
>>>> Phone: 877-848-9581 Ext. 1055
>>>> Direct: 419-610-2076
>>>> Fax: 440-209-7783
>>>> Email: lbetts@thoughtwm.com <pfernando@thoughtwm.com>
>>>> Web: http://www.thoughtwiremarketing.com <http://www.thoughtwm.com/>
>>>>
>>>>
>>>> On Wed, Apr 16, 2014 at 4:23 PM, Jarno van Driel <
>>>> jarnovandriel@gmail.com> wrote:
>>>>
>>>>> Hey folks,
>>>>>
>>>>> I just wanted you to know that after the last mailing I have been
>>>>> doing quite some reading as well extensive testing and am happy to inform
>>>>> you that Google now fully supports @itemid as global identifier and that
>>>>> linking to it actually works!
>>>>>
>>>>> Not only do I get the right results in Google's Structured data
>>>>> testing tool but in also Webmaster tools. I've been testing with @itemid on
>>>>> my own site, by having multiple objects link to the same entity, as well
>>>>> creating cycles by having entities point to each other, and everything
>>>>> returns the proper values and types.
>>>>>
>>>>> I have reworked the example Niklas provided in Microdata so you can
>>>>> see yourself:
>>>>> (don't feel like reading the code? than look at what the SDTT makes of
>>>>> it: http://bit.ly/1jLitKl)
>>>>>
>>>>> <body itemid="page" itemscope itemtype="http://schema.org/ItemPage">
>>>>> <link itemprop="copyrightHolder" href="corp">
>>>>>
>>>>> <article itemprop="text">
>>>>> <div itemid="article" itemscope itemtype="
>>>>> http://schema.org/Article">
>>>>> <link itemprop="publisher" href="corp">
>>>>>
>>>>> <h1 itemprop="name">How to copy properties in RDFa Lite &
>>>>> Microdata</h1>
>>>>> </div>
>>>>> </article>
>>>>>
>>>>> <footer itemprop="mentions" itemscope itemtype="
>>>>> http://schema.org/WPFooter">
>>>>> <p>
>>>>> <span itemid="corp" itemprop="about" itemscope itemtype="
>>>>> http://schema.org/Corporation">
>>>>> <a itemprop="url" href="http://www.example.org">
>>>>> <span itemprop="name">Corporation name</span>
>>>>> </a>
>>>>>
>>>>> <span itemprop="description">Corporation description</span>
>>>>> </span>
>>>>> </p>
>>>>> </footer>
>>>>> </body>
>>>>>
>>>>> Thanks for all the great input you have given me! I actually have hope
>>>>> again that I will be able to make sense of RDFa because of it. :)
>>>>>
>>>>>
>>>>> 2014-03-11 19:02 GMT+01:00 Richard H. McCullough <rhm@pioneerca.com>:
>>>>>
>>>>> You might want to steal some ideas from the mKR language.
>>>>>>
>>>>>> mKR lets you name any list of propositions, e.g.,
>>>>>> my propositions :: { proposition list };
>>>>>> and manipulate that list in numerous ways.
>>>>>>
>>>>>> You can add, delete, ... propositions
>>>>>> You can change the underlying class hierarchy
>>>>>> ...
>>>>>>
>>>>>> *Dick McCullough *
>>>>>> Context Knowledge Systems<http://mkrmke.org/ContextKnowledgeSystems.html>
>>>>>> mKE and the mKR language <http://mkrmke.org/mKEmKR.html>
>>>>>> mKR/mKE tutorial <http://mkrmke.org/doc/MKEtutorial.html>
>>>>>>
>>>>>> ------------------------------
>>>>>> Date: Tue, 11 Mar 2014 15:41:09 +0100
>>>>>> From: jarnovandriel@gmail.com
>>>>>> To: gregg@greggkellogg.net
>>>>>> CC: lindstream@gmail.com; public-rdfa@w3.org
>>>>>> Subject: Re: how do I copy some properties that are part of a bigger
>>>>>> pattern
>>>>>>
>>>>>>
>>>>>> Thanks for the sources Gregg. Some of 'm I know but with the new
>>>>>> insights I have now I bet some of 'm will make much more sense to me now.
>>>>>> I'll make sure to read it before asking more questions.
>>>>>>
>>>>>>
>>>>>> 2014-03-11 2:01 GMT+01:00 Gregg Kellogg <gregg@greggkellogg.net>:
>>>>>>
>>>>>> On Mar 10, 2014, at 5:07 AM, Jarno van Driel <jarnovandriel@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> "...There is no difference here between links and "nested" items..."
>>>>>> + "...Try the example..."
>>>>>> Thanks, you just made my brain explode. =)
>>>>>>
>>>>>> It's been a couple of years since my first attempts at understanding
>>>>>> RDFa - which failed miserably - since I have difficulty translating the W3
>>>>>> specifications in, for me, understandable rules on how it's supposed to be
>>>>>> used and what it can do. Your comments together with the RDFa Play outcome
>>>>>> succeeded where countless hours of reading specifications and experimenting
>>>>>> with markup have failed me. Seriously Niklas, thanks!
>>>>>>
>>>>>> Now as for the IRC meet, let that slide for now. A tsunami of
>>>>>> possibilities just flushed over me and I have to give it some time to let
>>>>>> it sink in. The first thought I had after reading your comments and seeing
>>>>>> the RDFa Play outcome was that writing an article about the use of @itemref
>>>>>> isn't that difficult but comparing that to rdfa:pattern just became a whole
>>>>>> lot more complicated. It now has become clear to me there is no 1:1
>>>>>> relation between the two - where I thought there was - and that RDFa offers
>>>>>> different solutions for many of the situations where one only can use
>>>>>> @itemref in Microdata. Which IS marvelous but which leaves me confused in
>>>>>> how to clarify that in an article without writing a series that's as thick
>>>>>> as the bible.
>>>>>>
>>>>>>
>>>>>> There are some great discussion threads on public-rdfa-wg in around
>>>>>> December 2012, starting with a proposal from Ivan. Check out the
>>>>>> "Reproducing Gregg/Niklas' thoughts ..." thread in
>>>>>> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Dec/thread.html
>>>>>> .
>>>>>>
>>>>>> As Niklas points out, the original concept was that a semantic
>>>>>> approach to property-copying, where we identified a resource and used it as
>>>>>> the source for copying properties, and remove the original "template"
>>>>>> resource. Basically, it could mostly be done using SPARQL with INSERT
>>>>>> DATA/DELETE DATA. It's worth looking at the thread to see some of the
>>>>>> thought processes that were going on at the time.
>>>>>>
>>>>>> I do know however that I want to limit myself to RDFa Lite since it's
>>>>>> the RDFa community's answer to Microdata. Or at least that's way I
>>>>>> understand it. So let me therefore ask, what are the differences between
>>>>>> RDFa and RDFa Lite? Is there any clear documentation about the difference
>>>>>> between the two I can read?
>>>>>>
>>>>>>
>>>>>> The RDFa Lite 1.1 recommendation <http://www.w3.org/TR/rdfa-lite/>
>>>>>> pretty much calls this out. Also, the RDFa 1.1 Primer <
>>>>>> http://www.w3.org/TR/xhtml-rdfa-primer/>. The key observation to the
>>>>>> LIte recommendation is that RDFa gets complicated when there are too many
>>>>>> attributes on an element, and the distinction between @about and @resource
>>>>>> can be subtle. Even now, I see people having a problem with Microdata, when
>>>>>> they use @itemprop on an anchor, and seem to expect the content of the
>>>>>> element, rather than the value of @href to be used as the property's value.
>>>>>> RDFa suffers from the same issue, but things get simpler when you restrict
>>>>>> yourself to using fewer attributes and avoid combining them together.
>>>>>>
>>>>>> That said, there is quite a bit of power in full RDFa 1.1,
>>>>>> particularly in the use of lists and chaining <
>>>>>> http://www.w3.org/TR/rdfa-core/#s_chaining>. Chaining is really
>>>>>> useful when you have a number of resource values from the same property,
>>>>>> for example the author list of a document. This avoids repeating markup,
>>>>>> but it is a sophisticated feature. IMO, you really can't write RDFa (full
>>>>>> or lite) or Microdata without running it through a distiller to verify that
>>>>>> it says what you mean.
>>>>>>
>>>>>> Let me widen the question: Are there any sources you guys can
>>>>>> recommend me to read about RDFa (Lite)?
>>>>>> Like I said earlier, it's been a couple of years for me, so I hope
>>>>>> new documentation exists by now, besides the W3 specifications.
>>>>>>
>>>>>>
>>>>>> Manu wrote a great post on the differences between RDFa Lite and
>>>>>> Microdata: <http://manu.sporny.org/2012/mythical-differences/>.
>>>>>>
>>>>>> Gregg
>>>>>>
>>>>>> 2014-03-09 18:10 GMT+01:00 Niklas Lindström <lindstream@gmail.com>:
>>>>>>
>>>>>> Hi Jarno,
>>>>>>
>>>>>> On Sun, Mar 9, 2014 at 5:08 PM, Jarno van Driel <
>>>>>> jarnovandriel@gmail.com> wrote:
>>>>>>
>>>>>> "...outputs two different nodes for what seemingly is the same
>>>>>> corporation..."
>>>>>> You're right in stating that this results in two instances of the
>>>>>> same Corporation. Which is the only way in Microdata to have an Item
>>>>>> (Corporation) be linked to other Items by means of different properties
>>>>>> (copyrightHolder & publisher). The following markup simply wouldn't work in
>>>>>> Microdata:
>>>>>> <div itemprop="manufacturer" itemref="corporation-data">
>>>>>>
>>>>>>
>>>>>> Yes, microdata (presumably) being a tree model prevents it from
>>>>>> connecting items together naturally. It's a big flaw. It only deals with
>>>>>> surface data, and says nothing about what it means. Perhaps @itemid makes
>>>>>> it into some kind of graph at times though, it's hard to tell when there
>>>>>> are no semantics explaining what that entails.
>>>>>>
>>>>>>
>>>>>> In Microdata itemref can only get additional info about a Type. You
>>>>>> can't use it on a property and then use itemref to get the @itemtype
>>>>>> elsewhere. That's why in Microdata I have to declare the Corporation twice,
>>>>>> to be able to link it to different entities (ItemPage & Article) by means
>>>>>> of different properties (copyrightHolder & publisher). Which brings me to
>>>>>> the question: Can this be accomplished RDFa Lite where it can't in
>>>>>> Microdata? - keeping in mind that in this specific example according to
>>>>>> schema.org rules the publisher and copyrightHolder are both expected
>>>>>> to 'have' a type and are not supposed to 'link' to a type.
>>>>>>
>>>>>>
>>>>>> Yes, it can. RDFa uses the RDF data model, which is a graph [1].
>>>>>> There is no difference here between links and "nested" items. You type and
>>>>>> (when needed) identify things, link them together and describe their
>>>>>> details with literals (texts) – all using properties. That is what I did in
>>>>>> the example given.
>>>>>>
>>>>>>
>>>>>> "...<p resource="#page">
>>>>>> <span property="copyrightHolder" typeof="Corporation"
>>>>>> resource="#corp">..."
>>>>>> The downside to this method is that the copyrighHolder-Corporation
>>>>>> now gets linked falsely. I quickly checked the output in Google's SDTT,
>>>>>> which showed the Corporation being a child of the WPFooter as opposed to
>>>>>> being the copyrightHolder of the ItemPage. The use of rdfa:pattern prevents
>>>>>> this happening as does a itemscope without an itemtype in Microdata e.g.
>>>>>> <div itemscope>.
>>>>>>
>>>>>>
>>>>>> The Google SDTT is wrong. It should recognize that <p
>>>>>> resource="#page"> sets the subject for nested statements (here ensuring
>>>>>> that the <#page> has the <#corp> as :copyrightHolder). It seems that adding
>>>>>> a @typeof:
>>>>>>
>>>>>> <p resource="#page" typeof="ItemPage">
>>>>>>
>>>>>> makes it behave somewhat more as expected. But note that that isn't
>>>>>> necessary in RDFa, it's just a workaround for a bug in the SDTT. (Try the
>>>>>> example out in e.g. <http://rdfa.info/play/> to see it more clearly.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Also, the resulting data here doesn't contain two distinct nodes for
>>>>>> what is apparently meant to be the same corporation."
>>>>>> True, but the two distinct nodes also have type-specific relations to
>>>>>> the two distinct items this example has, namely ItemPage and Article. Maybe
>>>>>> that info got a bit lost because I stripped out so much of the original
>>>>>> HTML. The source I took this from has an ItemPage with a gazillion other
>>>>>> types attached to it while the Article is just that, an Article, with it's
>>>>>> own set of properties, mostly separated from the rest of the content on the
>>>>>> ItemPage, only sharing data from the Corporation.
>>>>>>
>>>>>>
>>>>>> I think I see how you mean. But if you think of this in terms of the
>>>>>> RDF data model, the items simply are resources linked together (and
>>>>>> assigned some types, and described with textual properties), rather than
>>>>>> blocks of data tied to the page structure (or the microdata tree structure,
>>>>>> which hardly helps). In this model, the corporation is surely one thing,
>>>>>> connected to from the ItemPage using copyrightHolder, and from the Article
>>>>>> using publisher (both of which are fine since the thing linked to is of the
>>>>>> expected type).
>>>>>>
>>>>>>
>>>>>>
>>>>>> "I'd be happy to take a look at such examples as well."< br>
>>>>>> Maybe we should meet in an IRC session, like Gregg suggested, because
>>>>>> I'm convinced we can keep this argument-counterargument up for quite some
>>>>>> time. Not that I mind, since this mailing has already given me a ton to
>>>>>> think about, but simply to be more time-efficient. Just let me know what
>>>>>> you guys prefer, either way is fine with me.
>>>>>>
>>>>>>
>>>>>> I'm fine either way too. :) I tend to have intermittent bouts of
>>>>>> time, so mailing is usually better for examples. But I could go for a chat
>>>>>> over specifics if needed.
>>>>>>
>>>>>> Cheers,
>>>>>> Niklas
>>>>>>
>>>>>> [1]: http://www.w3.org/TR/rdf11-primer/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-03-09 14:19 GMT+01:00 Niklas Lindström <lindstream@gmail.com>:
>>>>>>
>>>>>> Hi Jarno and Gregg!
>>>>>>
>>>>>> It seems to me that this is a good example of where @itemref-like
>>>>>> functionality is quite unnecessary in RDFa. The #copyright-holder simply
>>>>>> contains a link from the page to the corporation, and the #publisher-url
>>>>>> and #publisher-description contain properties of that corporation. The
>>>>>> resulting microdata, however, outputs two different nodes for what
>>>>>> seemingly is the same corporation, so perhaps the example has been
>>>>>> simplified too much, thus obscuring what is actually needed?
>>>>>>
>>>>>> Still, In RDFa, instead of adding different @id:s to disparate parts
>>>>>> of the page which are about the same resource (and then listing them in
>>>>>> @itemref), you simply use @resource to capture the fact that a given block
>>>>>> is about it.
>>>>>>
>>>>>> Your example can thus be written like this in RDFa Lite:
>>>>>>
>>>>>> - - - 8< - - -
>>>>>>
>>>>>> <body vocab="http://schema.org/" typeof="ItemPage" resource="#page">
>>>>>> <article property="text">
>>>>>> <div typeof="Article">
>>>>>> <link property="publisher" resource="#corp">
>>>>>>
>>>>>> <h1 property="name">How to copy properties in RDFa Lite &
>>>>>> Microdata</h1>
>>>>>> </div>
>>>>>> </article>
>>>>>>
>>>>>> <footer property="mentions" typeof="WPFooter">
>>>>>> <div property="text">
>>>>>> <p resource="#page">
>>>>>> <span property="copyrightHolder" typeof="Corporation"
>>>>>> resource="#corp">
>>>>>> <a property="url" href="http://www.example.org">
>>>>>> <span property="name">Corporation name</span>
>>>>>> </a>
>>>>>>
>>>>>> <span property="description">Corporation description</span>
>>>>>> </span>
>>>>>> </p>
>>>>>> </div>
>>>>>> </footer>
>>>>>> </body>
>>>>>>
>>>>>> - - - >8 - - -
>>>>>>
>>>>>> In my opinion, this is a more convenient way of handling data smeared
>>>>>> out in a messy tag soup (with the results being shorter and more
>>>>>> legible). Of course, you need to name these resources, unless they already
>>>>>> have formal URIs, but that's easily done with a fragment identifier or a
>>>>>> bnode id. (And note that in microdata, you instead need to ensure that a
>>>>>> layout designer doesn't meddle with the @id values used by @itemref, for
>>>>>> quite different reasons (their use in CSS and JS).)
>>>>>>
>>>>>> Also, the resulting data here doesn't contain two distinct nodes for
>>>>>> what is apparently meant to be the same corporation.
>>>>>>
>>>>>> Remember, it is only when you need to duplicate a set of properties
>>>>>> for different resources that rdfa:copy is necessary. And even in those
>>>>>> circumstances, you might be able to leverage the way @resource can group
>>>>>> descriptions together, to build up one pattern from disparate parts of the
>>>>>> page.
>>>>>>
>>>>>> I'd be happy to take a look at such examples as well.
>>>>>>
>>>>>> Cheers,
>>>>>> Niklas
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 9, 2014 at 11:51 AM, Jarno van Driel <
>>>>>> jarnovandriel@gmail.com> wrote:
>>>>>>
>>>>>> I think your and my latest example just passed each other Gregg. I
>>>>>> guess I posted mine when you were writing yours because when I compare the
>>>>>> two I see we implemented the same workaround by means of additional
>>>>>> @resource.
>>>>>>
>>>>>> "I wouldn't recommend the use of included patterns in RDFa, but it
>>>>>> can be made to work."
>>>>>> I wouldn't recommend it either but unfortunately the everyday website
>>>>>> out there consists out of a HTML-soup which doesn't allow for Semantic
>>>>>> markup to be added in a nice and clean way. Now I mainly work on already
>>>>>> existing websites, where I have to make do with HTML that's already in
>>>>>> place. Therefore itemref or rdfa:pattern are indispensable when
>>>>>> organizing/linking data that's smeared out over many different HTML
>>>>>> elements on a page. I am very aware this results in markup that isn't
>>>>>> 'nice' but it helps create meaning even if the HTML is a mess.
>>>>>>
>>>>>> "P.S., I think it’s great that you’re trying to describe this for a
>>>>>> wider audience!"
>>>>>> Well, I'm not doing it alone. Aaron Bradley is acting as the devil's
>>>>>> advocate by asking me questions which mess up the solutions I provide.
>>>>>> Which in return forces me to come up with different solutions and ask a lot
>>>>>> of questions at the public-vocabs (and now here as well). :)
>>>>>>
>>>>>> So trying to do something for a bigger audience will most definitely
>>>>>> end up in something that has been contributed by many people. As always
>>>>>> this kind of stuff ends up being a multi-community/person effort since it
>>>>>> brings together so many different specializations and specifications.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Andy and Gregg,
>>>>>> Thanks for sharing your knowledge, I'll make sure re-share it and am
>>>>>> hopeful it will result in an article (or series of) which will try to serve
>>>>>> anybody who is (or should be) interested in this type of info.
>>>>>>
>>>>>>
>>>>>> 2014-03-09 6:46 GMT+01:00 Gregg Kellogg <gregg@greggkellogg.net>:
>>>>>>
>>>>>> On Mar 8, 2014, at 5:50 PM, Jarno van Driel <jarnovandriel@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> "..the @resource attributes get in the way.."
>>>>>> Could you explain this to me a bit more please Gregg? Because if I
>>>>>> parse my last markup through the Structured data linter and RDFa Play I get
>>>>>> 100% the same outcome as with your markup. Yandex and Google see the same
>>>>>> data as well (in a ever so slightly different manner).
>>>>>>
>>>>>> When I look at the output these parsers have no trouble extracting
>>>>>> the @resources as different rdfanodes. Unless I'm completely overlooking
>>>>>> something, or am breaking some cardinal rules, which both are feasible
>>>>>> since I just got around to looking more deeply into RDFa Lite.
>>>>>>
>>>>>>
>>>>>> In order to be able to reference the publisher-uri and
>>>>>> publisher-description information as patterns, they need to have an
>>>>>> identifier, which I supplied by adding @resource (and
>>>>>> @typeof=“rdfa:Pattern) to each. However, this changes the scope of their
>>>>>> properties relative to the copyright-holder.
>>>>>>
>>>>>> In you’re RDFa version you weren’t able to access the publisher-uri
>>>>>> or publisher-description, as you do from Microdata. The RDFa property
>>>>>> copying uses a resource of type rdfa:Pattern, which must be identified as a
>>>>>> resource. For this reason, I added the @resource and @typeof for both the
>>>>>> publisher-description and publisher-url. However, doing that, changes the
>>>>>> current subject for each of these, so the “url” and “description”
>>>>>> properties are allocated to different resources. To get around this, I
>>>>>> added the rdfa:copy properties both the the publisher reference, and to the
>>>>>> copyright-holder, so that the properties appear in each of them. I wouldn’t
>>>>>> recommend the use of included patterns in RDFa, but it can be made to work.
>>>>>>
>>>>>> I’d recommend both for Microdata and RDFa to keep references simple,
>>>>>> and using included references, while possible, can make things more
>>>>>> confusing. This is certainly not a pattern we were concerned about when
>>>>>> crafting the property copying mechanism in HTML+RDFa. They two really work
>>>>>> quite differently: Microdata requires full access to the DOM so that
>>>>>> referenced elements can be copied, which requires random access to the DOM.
>>>>>> The RDFa mechanism operates at a semantic level, by creating triples as
>>>>>> normal. RDFa is intended to work with streaming processors, where there is
>>>>>> no random-access to the DOM. The spec provides details of the rules which
>>>>>> are applied to achieve the effect of property copying [1], but it’s not
>>>>>> really magic to RDFa, and could just as easily be done for triples
>>>>>> extracted from Turtle, or even Microdata, if the appropriate copying rules
>>>>>> were applied.
>>>>>>
>>>>>> I understood that you didn’t know how to deal with a pattern embedded
>>>>>> in another pattern, which I attempted to address for you. I think that the
>>>>>> RDFa I provided does essentially what your Microdata does. If you want to
>>>>>> discuss more, we should probably meet on IRC.
>>>>>>
>>>>>> Gregg
>>>>>>
>>>>>> P.S., I think it’s great that you’re trying to describe this for a
>>>>>> wider audience!
>>>>>>
>>>>>> [1] http://www.w3.org/TR/rdfa-in-html/#implementing-property-copying
>>>>>>
>>>>>>
>>>>>> 2014-03-09 1:33 GMT+01:00 Gregg Kellogg <gregg@greggkellogg.net>:
>>>>>>
>>>>>> Hi Jarno, I don’t think you can do precicely what you want, since if
>>>>>> a pattern is included in another pattern, the @resource attributes get in
>>>>>> the way. You can do it by adding some more rdfa:copy properties. This is
>>>>>> what I came up with:
>>>>>>
>>>>>> <body vocab="http://schema.org/" resource="#item-page"
>>>>>> typeof="ItemPage">
>>>>>> <link property="rdfa:copy" href="#copyright-holder">
>>>>>>
>>>>>> <article property="text">
>>>>>> <div resource="#article" typeof="Article">
>>>>>> <div property="publisher" typeof="Corporation">
>>>>>> <link property="rdfa:copy" href="#publisher-url"/>
>>>>>> <link property="rdfa:copy" href="#publisher-description"/>
>>>>>> </div>
>>>>>>
>>>>>>
>>>>>> <h1 property="Name">How to copy properties in RDFa Lite &
>>>>>> Microdata</h1>
>>>>>> </div>
>>>>>> </article>
>>>>>>
>>>>>> <footer property="mentions" typeof="WPFooter">
>>>>>> <div property="text">
>>>>>> <p resource="#copyright-holder" typeof="rdfa:Pattern">
>>>>>> <span property="copyrightHolder" typeof="Corporation">
>>>>>> <link property="rdfa:copy" href="#publisher-url"/>
>>>>>> <link property="rdfa:copy" href="#publisher-description"/>
>>>>>> <span resource="#publisher-url" typeof="rdfa:Pattern">
>>>>>> <a id="publisher-url" property="url" href="
>>>>>> http://www.example.org" title>
>>>>>> <span property="name">Corporation name</span>
>>>>>> </a>
>>>>>> </span>
>>>>>>
>>>>>> <span resource="#publisher-description"
>>>>>> typeof="rdfa:Pattern">
>>>>>> <span id="publisher-description"
>>>>>> property="description">Corporation description</span>
>>>>>> </span>
>>>>>> </span>
>>>>>> </p>
>>>>>> </div>
>>>>>> </footer>
>>>>>> </body>
>>>>>>
>>>>>> Gregg Kellogg
>>>>>> gregg@greggkellogg.net
>>>>>>
>>>>>> On Mar 8, 2014, at 2:37 PM, Jarno van Driel <jarnovandriel@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> <body vocab="http://schema.org/" resource="#item-page"
>>>>>> typeof="ItemPage">
>>>>>> <link property="rdfa:copy" href="#copyright-holder">
>>>>>>
>>>>>> <article property="text">
>>>>>> <div resource="#article" typeof="Article">
>>>>>> <link property="publisher" typeof="Corporation" href=?????>
>>>>>>
>>>>>> <h1 property="Name">How to copy properties in RDFa Lite &
>>>>>> Microdata</h1>
>>>>>> </div>
>>>>>> </article>
>>>>>>
>>>>>> <footer property="mentions" typeof="WPFooter">
>>>>>> <div property="text">
>>>>>> <p resource="#copyright-holder" typeof="rdfa:Pattern">
>>>>>> <span property="copyrightHolder" typeof="Corporation">
>>>>>> <a id="publisher-url" property="url" href="http://www.example.org"
>>>>>> title>
>>>>>> <span property="name">Corporation name</span>
>>>>>> </a>
>>>>>>
>>>>>> <span id="publisher-description" property="description">Corporation
>>>>>> description</span>
>>>>>> </span>
>>>>>> </p>
>>>>>> </div>
>>>>>> </footer>
>>>>>> </body>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Received on Friday, 18 April 2014 14:40:20 UTC