- From: W. Nema <waleed.nema@gmail.com>
- Date: Wed, 22 Jan 2014 06:10:41 +0300
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Cc: Robert Sanderson <azaroth42@gmail.com>, public-openannotation <public-openannotation@w3.org>
- Message-ID: <CAFcmOM59nBzNffLTiiDGDKuN23m-wVpGF_vhfEp+FgY7T+v0eQ@mail.gmail.com>
I thought one important aspect of standardization is vocabulary. Why change
it at all? If simplification is needed why not do it in the OA language too?
On Tue, Jan 21, 2014 at 11:43 PM, Paolo Ciccarese <paolo.ciccarese@gmail.com
> wrote:
>
>
>
> On Tue, Jan 21, 2014 at 3:41 PM, Robert Sanderson <azaroth42@gmail.com>wrote:
>
>>
>> 1. How about "on"?
>> Then the body is a comment on the target, or a tag is a tag on the
>> target.
>>
>
> +1
>
>
>>
>> 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.
>>
>
> Agree, 'publisher' would create confusion. We want to keep it for the
> "right' scenario.
>
>
>>
>>
>>
>> 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/CSq9Jsdd3zkwhere 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.
>>>
>>
>>
>
>
> --
> 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 Wednesday, 22 January 2014 04:20:11 UTC