- From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Date: Wed, 22 Jan 2014 08:54:15 -0500
- To: Ivan Herman <ivan@w3.org>
- Cc: public-openannotation <public-openannotation@w3.org>, "t-cole3@illinois.edu" <t-cole3@illinois.edu>
- Message-ID: <CAFPX2kDJZ2fwwiGhxdQz+EOLw4SUWxLW_Hh82tpCJdCKn_wbDA@mail.gmail.com>
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 13:54:46 UTC