W3C home > Mailing lists > Public > public-annotation@w3.org > April 2016

Re: [web-annotation] HTML Serialization Use Cases

From: Ivan Herman via GitHub <sysbot+gh@w3.org>
Date: Mon, 11 Apr 2016 10:08:04 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-208266483-1460369283-sysbot+gh@w3.org>

> On 10 Apr 2016, at 18:07, Tim Cole <notifications@github.com> wrote:
> However, because we also shorten some names in our JSON-LD context 
document, I'm not sure just addressing the namespaced classes and 
properties issue alone is sufficient to fully facilitate the mapping 
between RDFa and JSON-LD in HTML, if that's really what we want to do.
 In our own namespace we have about a dozen of these shortened 
> body, hasBody
> target, hasTarget
> source, hasSource
> selector, hasSelector
> state, hasState
> scope, hasScope
> startSelector, hasStartSelector
> endSelector, hasEndSelector
> motivation, motivatedBy
> purpose, hasPurpose
> stylesheet, styledBy
> cached, cachedSource
> We already argued a bit about these. Not sure we want to re-open 
this discussion at this late date. I personally think it desirable to 
maintain backward compatibility. But in keeping with idea of 
eliminating keys in foreign namespaces, if compelling enough case 
could be made, we could maintain 'superseded' terms as schema.org does
 (e.g., schema:review supersedes schema:reviews, schema:provider 
supersedes schema:carrier) or in some other way maintain longer term 
while preferring shorter term in RDFa as well as in json-ld. For those
 going back and forth between json-ld and other rdf serializations, it
 would make life a tiny bit easier.
> All in all, seems like a lot work preceded by extensive discussion 
(and potentially heated argument). Do not want to get derailed. But if
 there is consensus that we want the RDFa to look more like our 
json-ld (which is what schema.org clearly wanted) in order to 
facilitate serialization in HTML, these changes would go a long way in
 that direction.
You are right, this is an issue I did not consider.

I do not want to get into this argument either. I would see we have 
two alternative strategies here, and we should strictly limit 
ourselves to these two.

1. For RDFa we use the terms in the vocabulary. No change *at all*, 
just in the namespace.
2. For RDFa we use the terms of JSON-LD. Again, no change *at all*, 
just an alias from that term to the vocabulary.

I do not think we should reopen *any* terminology issue on these, it 
is bikeshedding at this point.

There are pros and cons for both. I am personally tempted to go for 
(2), because if users may want to mix the possibilities to include 
JSON-LD in the script and also use RDFa (which is a perfectly viable 
option) then (2) allows a mess. On the other hand, hard core RDF 
people would want to rely on the formal vocabulary terms (but, then 
again, hard core RDF people would have no problem using namespaces, 
ie, this aliasing exercise may be of no interest for them in the first

GitHub Notification of comment by iherman
Please view or discuss this issue at 
 using your GitHub account
Received on Monday, 11 April 2016 10:08:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:45 UTC