- From: Leyla Jael García Castro <leylajael@gmail.com>
- Date: Wed, 22 Jan 2014 21:06:55 +0000
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Cc: Ivan Herman <ivan@w3.org>, public-openannotation <public-openannotation@w3.org>, "t-cole3@illinois.edu" <t-cole3@illinois.edu>
- Message-ID: <CACLxDV4h+gMN0geHBTc7U0Pm5+X0S4m5e4ZQHhY0fPK8JiCsqw@mail.gmail.com>
Hi all,
Probably no related to what you have discussed in this thread but to RDFa.
I think schema.org is pretty common in the RDFa users. Will we map OA to
RDFa? There is no need from what I understand, but maybe it would be a good
idea to check what similar is in there.
Cheers,
Leyla
On Wed, Jan 22, 2014 at 1:54 PM, Paolo Ciccarese
<paolo.ciccarese@gmail.com>wrote:
> Hi Ivan,
> comments inline.
>
>
> On Wed, Jan 22, 2014 at 5:30 AM, Ivan Herman <ivan@w3.org> wrote:
>
>> Hey Paolo,
>>
>> see below.
>>
>> On 22 Jan 2014, at 04:48 , Paolo Ciccarese <paolo.ciccarese@gmail.com>
>> wrote:
>>
>> > Dear Ivan and all,
>> > I would start from the example Ivan included in a previous email
>> http://lists.w3.org/Archives/Public/public-openannotation/2014Jan/0038.html
>> > I also copied it to the Wiki
>> http://www.w3.org/community/openannotation/wiki/RDFa were we can collect
>> the results of the discussion.
>> >
>> > Here below a couple of initial considerations/exercises. Ivan I am
>> trying to understand this myself so please chime in and explain where
>> necessary.
>> >
>> > 1) Target
>> >
>> > Current:
>> > <blockquote property="hasTarget"
>> > resource="http://example.com/sourcedoc.html"
>> > cite="http://example.com/sourcedoc.html"
>> > data-prefix="essential feature of the memex. "
>> > data-suffix=" When the user is building a tra" typeof="">
>> > <p>The process of tying two items together is the important
>> thing.</p>
>> > <footer>
>> > - <cite>
>> > <a href="http://en.wikipedia.org/wiki/Vannevar_Bush">
>> > <span>Vannevar Bush</span>
>> > </a>
>> > </cite>
>> > </footer>
>> > </blockquote>
>> >
>> > Using the distiller this becomes:
>> > ...
>> > "hasTarget": "http://example.com/sourcedoc.html"
>> > ...
>> >
>> > and not what I would expected given Doug example:
>> > "hasTarget": {
>> > "@id": "http://example.com/specifictarget/0001",
>> > "@type": "SpecificResource",
>> > "hasSelector": {
>> > "@id": "http://example.com/selector/0001",
>> > "@type": "TextQuoteSeletor",
>> > "prefix": "essential feature of the memex. ",
>> > "match": "The process of tying two items together is the
>> important thing.",
>> > "suffix": " When the user is building a tra"
>> > },
>> > "hasSource": "http://example.com/sourcedoc.html"
>> > },
>> >
>> > Was that intentional? Were you (or Doug) thinking of using
>> 'data-prefix' and 'data-suffix' as shortcuts?
>>
>> Indeed. As I said back then, I was not not sure what really the intention
>> of Doug was and how it could/should be expressed in OA (ie, how to express
>> the relationship to Bush.), so I skipped over this. There were some
>> separate mails on this since which I did not follow in details,
>> unfortunately, but I guess that is what you use below.
>>
>> >
>> > This is an exercise for a more complete - and more complex! - approach,
>> which allow the user to add the SpecificResource/Selector info if needed
>> (only blockquote here):
>> >
>> > <blockquote property="hasTarget" resource="
>> http://example.com/specifictarget/0001"
>> > typeof="SpecificResource" cite="http://example.com/sourcedoc.html"
>> >
>> > <details>
>> > <summary>Source</summary>
>> > <a property="hasSource" resource="
>> http://example.com/sourcedoc.html" href="
>> http://example.com/sourcedoc.html">http://example.com/sourcedoc.html</a>
>> > </details>
>> > <div property="hasSelector" resource="
>> http://example.com/selector/0001" typeof="TextQuoteSeletor">
>> > <p property="prefix" style="display: none;">essential feature
>> of the memex. </p>
>> > <p property="exact">The process of tying two items together is
>> the important thing.</p>
>> > <p property="suffix" style="display: none;"> When the user is
>> building a tra</p>
>> > <div>
>> > <footer>
>> > - <cite>
>> > <a href="http://en.wikipedia.org/wiki/Vannevar_Bush">
>> > <span>Vannevar Bush</span>
>> > </a>
>> > </cite>
>> > </footer>
>> > </blockquote>
>> >
>> > I am using 'details' defined as 'The details element represents a
>> disclosure widget from which the user can obtain additional information or
>> controls.' With the idea that the source could be shown/hidden. Probably
>> the 'summary' element can be omitted.
>> >
>> > This markup - that could be simplified - generates the above JSON-LD
>> snippet.
>> > It is obviously more complicated.
>>
>> Right. I have made a little bit simpler below, but not much:
>>
>> <blockquote property="hasTarget"
>> typeof="SpecificResource" cite="
>> http://example.com/sourcedoc.html" >
>> <details>
>> <summary>Source</summary>
>> <a property="hasSource" resource="
>> http://example.com/sourcedoc.html" href="
>> http://example.com/sourcedoc.html">http://example.com/sourcedoc.html</a>
>> </details>
>> <div property="hasSelector" typeof="TextQuoteSeletor">
>> <meta property="prefix" content="essential feature of the
>> memex.">
>> <p property="exact">The process of tying two items
>> together is the important thing.</p>
>> <meta property="suffix" content="When the user is
>> building a tra">
>> <div>
>> <footer>
>> - <cite>
>> <a href="http://en.wikipedia.org/wiki/Vannevar_Bush
>> ">
>> <span>Vannevar Bush</span>
>> </a>
>> </cite>
>> </footer>
>> </blockquote>
>>
>> One of the simplifications is a matter of choice: I would expect blank
>> nodes are perfectly all right for what you referred to as .../001; unless
>> other parts of the system needs explicit URI-s for these, they are
>> perfectly fine as blank nodes imho.
>>
>
> That looks a lot more readable.
>
> In the spec we talk about blank nodes in regards to embedded textual
> content.
> The above would generate something like this:
>
> "hasTarget": {
> "@type": "SpecificResource",
> "hasSelector": {
> "@type": "TextQuoteSeletor",
> "exact": "The process of tying two items together is the important
> thing.",
>
> "suffix": "When the user is building a tra",
> "prefix": "essential feature of the memex."
> },
> "hasSource": "http://example.com/sourcedoc.html"
> },
>
> Tim, Rob? Thoughts?
>
>
>>
>> The other, more important change: when using RDFa, the <meta> and <link>
>> elements are valid everywhere in the document (much as is the case in
>> microdata), and I think that is a much cleaner pattern than using a
>> @style="display:none".
>>
>
> That is very good for 'quotes'. Sometimes (this is the case in my
> application) prefix and suffix can be displayed as context for the target
> match. In that case I would still probably stick to a <p> (or maybe a
> <details> that can be shown or hidden).
>
>
>>
>> Note that the extra complication here is conceptual and not OA or RDFa
>> specific: it is the stable URI/anchor issue for a quote in another
>> document. That issue, in general, should be part of the WG (although I
>> personally like the approach taken in OA, which is pretty pragmatic...)
>>
>
> Agree.
>
>
>>
>>
>> >
>> > 2) Embedded textual body
>> >
>> > Current:
>> > <p property="hasBody" typeof=""><span property="rdf:value">Annotations
>> are at the Web's core.</span></p>
>> >
>> > According to specs - and forgetting dc:format for now - that should be
>> something like:
>> > <p property="hasBody" typeof="cnt:ContentAsText"><span
>> property="cnt:chars" >Annotations are at the Web's core.</span></p>
>> > or, assuming to have a RDFS aware processor (as the domain of cnt:chars
>> is cnt:ContentAsText), just:
>> > <p property="hasBody" typeof=""><span property="cnt:chars">Annotations
>> are at the Web's core.</span></p>
>> >
>> > The above would generate something on the lines of:
>> > hasBody": {
>> > "@type": "cnt:ContentAsText",
>> > "cnt:chars": "Annotations are at the Web's core."
>> > },
>> >
>> > Again, at this stage, these are incomplete exercises for discussion
>> purposes.
>> > Comments are more than welcome.
>> >
>>
>> Yes, that is correct.
>>
>> Unfortunately (see on the wiki) the @prefix="cnt: http://...." is
>> necessary in this case, which makes it a bit more complex because namespace
>> have to be defined. This is not the case for foaf, because that is part of
>> RDFa's initial context, as a widely used vocabulary, and therefore it can
>> be used without declaration. I wonder whether there are no alternatives to
>> 'cnt' that would make this simpler.
>>
>
> Clearly, in the case of RDFa, using pre-defined prefixes is convenient.
> However, for now, as the current spec is recommending using cnt, I will
> just add this to the wiki (with a prefix declaration) and I will write a
> note.
>
>
>>
>> (The RDFa WG shied away from the definition of a @context of the same
>> power as in JSON-LD. We had it defined, there were actually implementations
>> for it at the time, but the issue of 'what happens if the context is not
>> available' became a stumbling block, because it would have made the output
>> of the RDFa processing unusable. JSON-LD was probably less shy on this but,
>> also, I guess what prevailed was that the JSON content still made some
>> sense, so an unreachable @context may not have been such a problem. I
>> personally think it is a pity, but, well, that is the way it is...)
>>
>
> I will update the wiki and shortly follow with other RDFa related things,
> thank you,
> Paolo
>
>
>
>>
>> Thanks!
>>
>> Ivan
>>
>>
>> > Paolo
>> >
>> >
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> GPG: 0x343F1A3D
>> FOAF: http://www.ivan-herman.net/foaf
>>
>>
>>
>>
>>
>>
>
>
> --
> Dr. Paolo Ciccarese
> http://www.paolociccarese.info/
> Biomedical Informatics Research & Development
> Instructor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> Member of the MGH Biomedical Informatics Core
> +1-857-366-1524 (mobile) +1-617-768-8744 (office)
>
> CONFIDENTIALITY NOTICE: This message is intended only for the
> addressee(s), may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to
> any other party without the permission of the sender.
> If you have received this message in error, please notify the sender
> immediately.
>
Received on Wednesday, 22 January 2014 21:07:47 UTC