- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Tue, 21 Jan 2014 12:41:10 -0800
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Cc: public-openannotation <public-openannotation@w3.org>
- Message-ID: <CABevsUFRYEY+zn3juMiEdm75N0G1hrbGiwCZ4MZ6pM3k4NA45g@mail.gmail.com>
1. How about "on"?
Then the body is a comment on the target, or a tag is a tag on the target.
2. Agreed. Atom uses the term "generator". Twitter uses "source", and only
has one timestamp, "created_at".
Previously we've used the terms generator and generatedAt in preference to
serializedBy/At, which would be one option.
I would prefer not to use "publisher" as that would be confusing to
companies that consider themselves digital publishers.
Any further suggestions?
R
On Tue, Jan 21, 2014 at 12:33 PM, Paolo Ciccarese <paolo.ciccarese@gmail.com
> wrote:
> Rob,
> feedback on these two:
> 1) oa:hasTarget : about
> Because of the inversion with Tags and Semantic Tags.
> I would prefer 'target' or 'on' even if I know it can be confused with a
> timestamp.
>
> 2) oa:serializedBy : client
> Because I serialize the annotation in OA format mostly from a server.
> Just to avoid confusion I would change that. Not sure what to though
> (serializer? publisher?)
> I would also keep oa:serializedBy and oa:serializedAt aligned
> terminologically speaking (serializer/serialized or publisher/published).
>
> I feel pretty comfortable with all the rest.
>
> Best,
> Paolo
>
>
>
> On Tue, Jan 21, 2014 at 1:54 PM, Robert Sanderson <azaroth42@gmail.com>wrote:
>
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> 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 (mobile) +1-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 Tuesday, 21 January 2014 20:41:42 UTC