Re: Friendly JSON serialization (Was: Annotation Serializations)

To kick this off with a strawman mapping:


Annotation:

oa:hasTarget :       about
oa:hasBody :         body
oa:motivatedBy :    reason
oa:annotatedBy :    user
oa:annotatedAt :     time
oa:serializedBy :    client
oa:serializedAt :     published
oa:styledBy :         stylesheet
oa:equivalentTo :    copyOf

Resources:

cnt:chars :         content
cnt:bytes :         bytes
dc:format :         format
dc:language :     lang
foaf:page :         page
rdfs:label :         label


Agents:

foaf:name :        name
foaf:mbox :        email
foaf:homepage : homepage
foaf:openid :       openid
foaf:nick :          nick


SpecificResources:

oa:hasSource :      full
oa:hasSelector :    selector
oa:hasState :         state
oa:hasScope :        seenIn
oa:styleClass :       style
oa:when :               when
oa:cachedSource :  cachedAt
dct:conformsTo :     spec


Selectors:

oa:start :  start
oa:end :    end
oa:prefix : prefix
oa:suffix : suffix
oa:exact : quote
rdf:value : value


Multiplicity:

NB -- I think we can simplify this part of the spec a lot by JUST using
rdf:Lists.  So I present two proposals, one for the current spec and then
for the proposed change.

1. Current Spec.

oa:default : default
oa:item : items
rdf:first : first
rdf:rest : rest


2. Proposal for simplification

We can make better use of the JSON list construction (and other
serializations) by not having a multi-class object, and instead only ever
using the list as an anonymous object of a predicate, say oa:items.  After
the discussion last time, the serialization algorithm for JSON-LD was
updated so our current spec does now work at least without randomly
dropping out information.

Thus oa:Choice becomes:
{ "@type" : "Choice",
  "items" : [default, firstOption, secondOption]
}

And oa:Composite and oa:List collapse to:
{ "@type" : "List",
  "items" : [first, second, third]
}


Classes:

* We predefine them all without their prefixes, and drop super-class names
(eg oa:FragmentSelector --> Fragment)
* Make a simpler term for SpecificResource of "Segment" -- anyone who knows
the model will understand that they can also use State and Styles with it,
even if it's not a "segment" per se.

--------

Thus, the simple example from the spec:

{
    "@context": "http://www.w3.org/ns/oa-context-new.json",
    "@type": "Annotation",
    "body": "http://www.example.org/body1",
    "about": "http://www.example.org/target1"
}

And the more complex example:

{
    "@context": "http://www.w3.org/ns/oa-context-20130208.json",
    "@id": "http://www.example.org/annotations/anno1",
    "@type": "Annotation",

    "time": "2012-11-10T09:08:07",
    "user": {
        "@id": "http://www.example.org/people/person1",
        "@type": "Person",
        "email": "mailto:person1@example.org",
        "name": "Person One"
    },

    "reason" : "commenting",
    "body": {
        "@type": "Text",
        "content": "This is part of our logo"
    },
    "about": {
        "@type": "Segment",
        "selector": {
            "@type": "Fragment",
            "value": "xywh=10,10,5,5"
            "spec": "http://www.w3.org/TR/media-frags/",
        },
        "full": {
            "@id": "http://www.example.org/images/logo.jpg",
            "@type": "Image"
        }
    }
}



Thoughts?

Rob


On Tue, Jan 21, 2014 at 3:18 AM, Ivan Herman <ivan@w3.org> wrote:

> @context rules:-)
>
> Ivan
>
> On 20 Jan 2014, at 21:26 , Robert Sanderson <azaroth42@gmail.com> wrote:
>
> >
> > Doug,
> >
> > My experience is the same.  In IIIF [1], we specifically did NOT use the
> OA context mapping and went with something less RDFy and more in line with
> the domain.   We went even further than your suggestion, with "hasTarget"
> being just "on".  This is one great advantage of JSON-LD, that the
> serialization can be very different from the (abstract) data model while
> still enabling semantic interoperability.
> >
> > I could easily imagine something like:
> >
> > {
> >   "@type" : "Annotation",
> >   "reason" : "commenting",
> >   "body" : "http://example.net/body",
> >   "about" : "http://example.org/target"
> > }
> >
> > as being more palatable than the current RDF centric context.  Again, I
> think this is something that we can derive some criteria for, redesign,
> solicit feedback and iterate on.
> >
> > Rob
> >
> > 1 --
> http://www.shared-canvas.org/datamodel/iiif/metadata-api.html#Annotation
> >
> >
> >
> > On Mon, Jan 20, 2014 at 12:13 PM, Doug Schepers <schepers@w3.org> wrote:
> > Hi, Rob–
> >
> > I couldn't agree more with Randall and Blaine. I was struck by how
> clumsy the predicate-like syntax felt to me; doubtless this is just an
> aesthetic from my background in JS, HTML, CSS, SVG, etc., but I think it's
> how most web developers would react as well.
> >
> > If there's a way to have terms that map from JSON-friendly syntax to
> RDF-friendly syntax, that would be really great (e.g., "hasBody" and "body"
> are quivalent; similarly for "hasTarget" -> "target", "annotatedBy" ->
> "annotator", "annotatedAt" -> "timstamp", and so on).
> >
> > Regards-
> > -Doug
> >
> >
> > On 1/20/14 1:07 PM, Robert Sanderson wrote:
> >
> > Second item from the discussion seems to be the availability of a web
> > developer friendly JSON serialization.
> >
> > Some background -- we have been asked for JSON serializations for at
> > least 3 years. Here is one such request of many, from 2011:
> > https://groups.google.com/forum/#!topic/oac-discuss/CSq9Jsdd3zk where we
> > kicked the can down the road waiting for JSON-LD to come along.
> >
> > Which it has, and is the recommended serialization for Open Annotation.
> >
> > So the question is not the JSON serialization's existence, but its
> > developer friendliness, and whether we can do any better while remaining
> > conformant with the JSON-LD specification.
> >
> > I think that would be a great discussion to have, or rather to restart,
> > as it was brought up in point 2 of this thread:
> >
> http://lists.w3.org/Archives/Public/public-openannotation/2013Apr/0015.html
> >
> >
> > Rob
> >
>
>
> ----
> 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
>
>
>
>
>
>