- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 23 Jan 2014 13:28:32 +0100
- To: Doug Schepers <schepers@w3.org>
- Cc: Leyla Jael García Castro <leylajael@gmail.com>, Paolo Ciccarese <paolo.ciccarese@gmail.com>, public-openannotation <public-openannotation@w3.org>, "t-cole3@illinois.edu" <t-cole3@illinois.edu>
- Message-Id: <C89A2A7B-6121-4525-9597-A0B53C6FD008@w3.org>
On 23 Jan 2014, at 08:08 , Doug Schepers <schepers@w3.org> wrote:
> Hi, Leyla–
>
> I think there's a lot of merit in that idea.
>
> That's actually the path I started down as part of my strawman, but then I realized that:
>
> 1) I was at risk of diverging so far from something recognizable as Open Annotations that it would probably be a bridge too far as a starting point for a conversation;
>
> 2) I actually preferred moving away from RDFa as much as possible into a mapping between OA entities and existing or possible HTML elements;
>
> 3) I was headed deep down the rabbit hole.
>
> So I popped my head back up and threw my strawman together with a bit of help with some RDF experts (butchering their advice so much that I won't implicate them).
>
> I have no objections to Rob, Paolo, and Ivan going through the exercise of making a proper RDFa characterization, though I'm uncertain I'd be skilled enough to contribute to that; but if nothing else, it could serve as a starting point to see if we can simplify to something more like the average web developer might produces, and given the uptake of Schema.org vocabularies, I imagine that that could well be the end-point.
I think the usage of the schema.org vocabulary or not is a bit separate from RDFa.
Mapping OA onto schema.org is possibly doable, but may require changing some part of the OA model as a whole. I must admit I have not yet considered this, and I am not sure anybody did think about it in the OA CG; it is certainly something worth considering. I would expect that some portions of the OA model would be forced to go through some simplification by doing so.
Also, formally, an upcoming WG would not have the prerogative to define a standard mapping of OA to schema.org; that is the prerogative of the schema.org partners. They decide whether a schema.org vocabulary would be accepted into the main tree or not. That being said, our current contacts with the schema.org people are excellent, so working out something in practice is definitely doable.
The question of course is whether annotations are a worthy target for the search engines; after all, that is what schema.org is all about. If we decide to go down that route, we would have to contact them asap.
Leyla, thanks for having raised this.
Ivan
>
> It might also be worthwhile getting some OA stuff into Schema.org, if it comes to that.
>
> Regards-
> -Doug
>
> On 1/22/14 4:06 PM, Leyla Jael García Castro wrote:
>> Hi all,
>>
>> Probably no related to what you have discussed in this thread but to RDFa.
>> I think schema.org <http://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 <mailto:paolo.ciccarese@gmail.com>> wrote:
>>
>> Hi Ivan,
>> comments inline.
>>
>>
>> On Wed, Jan 22, 2014 at 5:30 AM, Ivan Herman <ivan@w3.org
>> <mailto:ivan@w3.org>> wrote:
>>
>> Hey Paolo,
>>
>> see below.
>>
>> On 22 Jan 2014, at 04:48 , Paolo Ciccarese
>> <paolo.ciccarese@gmail.com <mailto: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 <tel:%2B31-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 <tel:%2B1-857-366-1524> (mobile) +1-617-768-8744
>> <tel:%2B1-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.
>>
>>
>
>
----
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
Received on Thursday, 23 January 2014 12:28:26 UTC