Re: [web-annotation] HTML Serialization Use Cases

Let's be concrete. Our json-ld context document currently maps 10 
classes, 23 properties and 1 attribute to a total of 8 namespaces 
(based on a quick count). I may have missed a few enumerations and/or 
values we draw from these and other namespaces (there are 12 
namespaces in addition to our own reference in current draft of our 
json-ld context document), but may not matter since arguably you might
 want to keep these. It's the borrowed properties that are the main 
issue.

as: "http://www.w3.org/ns/activitystreams#"
as:Application
as:first
as:generator
as:items, "@container": "@list"
as:last
as:next
as:OrderedCollection
as:OrderedCollectionPage
as:partOf
as:prev
as:startIndex
as:totalItems

dc: "http://purl.org/dc/elements/1.1/"
dc:format

dcterms: "http://purl.org/dc/terms/"
dcterms:conformsTo
dcterms:creator
dcterms:issued
dcterms:modified
dcterms:rights

dctypes: "http://purl.org/dc/dcmitype/"
dctypes:Dataset
dctypes:MovingImage
dctypes:Sound
dctypes:StillImage
dctypes:Text

foaf: "http://xmlns.com/foaf/0.1/"
foaf:homepage
foaf:mbox
foaf:mbox_sha1sum
foaf:name
foaf:nick
foaf:Organization
foaf:Person

rdf: "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
rdf:value

rdfs: "http://www.w3.org/2000/01/rdf-schema#"
rdfs:label

schema: "http://schema.org/"
schema:audience

That's a lot of owl:sameAs assertions, but assuming no name collisions
 (I don't think we have any), I personally have no strong opinions one
 way or another. Namespaces are convenient in XML  and some other 
serializations, not really so much in JSON. There are advantages in 
not being seen to re-invent the wheel, and not having to maintain 
vocabulary terms in parallel, but as long as we acknowledge 
inspiration, I could live with this kind of change given a strong 
enough rationale. By the way, 
http://schema.org/docs/schema_org_rdfa.html does acknowledge source, 
it just doesn't use owl:sameAs. Personally I'd rather be more explicit
 and link term-by-term to original namespace using owl:sameAs, as was 
suggested. 

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 
aliases:

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. 

Ultimately may depend on the strength of disagreements within the 
Group and the balance we settle on for HTML Serialization note between
 JSON-LD, RDFa, and extensions to HTML (the latter would presumably 
require its own distinct mapping).

What do others think?  Go ahead. Be honest (but keep it clean and no 
personal attacks). 


-- 
GitHub Notification of comment by tcole3
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/147#issuecomment-208082382
 using your GitHub account

Received on Sunday, 10 April 2016 22:07:13 UTC