- From: Leyla Jael García Castro <leylajael@gmail.com>
- Date: Thu, 23 Jan 2014 09:47:56 +0000
- To: Douglas Schepers <schepers@w3.org>
- Cc: public-openannotation <public-openannotation@w3.org>, t-cole3@illinois.edu, Ivan Herman <ivan@w3.org>, Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Message-ID: <CACLxDV5=QJtsr3YCWKjXLKOzRqXpGv4Q2fFedwAtTz_NOHGiyw@mail.gmail.com>
Hi Doug,
Just some thoughts below
On Jan 23, 2014 7:08 AM, "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 was not sure whether it was a good idea or not, or whether it has been
mention before but, well when schema.org came to my mind when seeing RDFa
>
> 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.
Yes, I think it is worth to see what they have there. I would probably use
OA directly but if something similar is there, mappings can be suggested or
documented.
>
> It might also be worthwhile getting some OA stuff into Schema.org, if it
comes to that.
That could be too. I do not know how easy the RDFa community adopts
vocabularies outside schema.org, it is possible of course, there are no
limitations. Maybe some strategies to make it easier for people in RDFa
community to know about OA could be (that would work for us on too)
Cheers,
Leyla
>
> 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.
>>
>>
>
>
Received on Thursday, 23 January 2014 09:48:26 UTC