Re: Suggestions from iAnnotate Conference

All good points, thanks Antoine!

Is there room for a community conventions document along side the
specification that lists some of these things perhaps, rather than being
within the spec itself?

Rob


On Wed, Apr 24, 2013 at 2:24 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi Rob,
>
> On the license rights I strongly suggest to keep it just as the issue of
> "creator" is handled right now at
> http://www.openannotation.org/**spec/core/core.html#Provenance<http://www.openannotation.org/spec/core/core.html#Provenance>
> I.e., implementers are encouraged to attch some property that reflects the
> creator, and to do so using existing vocabularies like Dublin Core.
>
> If you propose a specific solution for rights in the spec, then I don't
> see why we could avoid presenting a solution for creator and a couple of
> other properties, which are even more important than rights.
>
> Besides, any given solution is likely to be questionable. Your current
> suggestion hints that dc:rights should be associated with the Annotation. I
> agree sometimes the granularity of rights may be at individual annotation,
> but I expect that very often data providers would want to express rights at
> the level for an entire dataset (a set of annotations, possibly with other
> type of data). This may be better done at the level of the entire data,
> either in a named graph or via other solution (even rights on the RDF
> file). Suggesting in the spec the specification of dc:rights for every
> annotation seems a dangerous thing to do.
>
> Antoine
>
>
>
>> Dear all,
>>
>> Two weeks ago there was a very successful conference in San Francisco:
>> http://www.iAnnotate.org/
>> Some suggestions were raised which I will endeavor to paraphrase.
>>
>> * From Puneet Kishor of Creative Commons:
>> There should be an explicit license/rights statement for the annotation,
>> or any of the other resources.
>>
>> Rob: Agreed. I propose that we add dcterms:rights to the provenance table
>> in:
>> http://www.openannotation.org/**spec/core/core.html#Provenance<http://www.openannotation.org/spec/core/core.html#Provenance>
>> Although this is clearly possible already just not stated, it seems an
>> important enough use case to be included in the specification itself.
>>
>> And an additional question: How do we determine which fields are worth
>> discussing in the specification and which are community driven? For example
>> rdfs:label / dc:title for an Annotation seems like another very common
>> property that could benefit from standardization.
>>
>>
>> * From Randall Leeds of Hypothes.is and Blaine Cook of Poetica:
>> The revised context misses the point of JSON-LD contexts, which are to
>> make the serialization as natively JSON friendly as possible. The "hasFoo"
>> style properties should be made more JSON-esque rather than RDF-esque.
>>
>> Rob: Which is what we used to have, and then changed it to mirror the RDF
>> predicates.
>> The JSON context to me is where we can make the lives of developers
>> easier ... but we need more information on what is easier and what isn't.
>> It seems like further discussion would be useful as this is an area where
>> getting it right will make a large different to implementations with no
>> added cost to the model or semantics.
>>
>>
>> * Nick Stenning previously of the Open Knowledge Foundation, plus others:
>> Interoperability comes from APIs not [just] data models. How do I get
>> these Annotations?
>>
>> Rob: HTTP is the API. However there was a long and very good discussion
>> about how exactly that should work. Should there be a companion API
>> document? Or should have a further section in the publishing module to
>> explain a simple REST API using the JSON-LD serialization as payload?
>>
>>
>> Many thanks all,
>>
>> Rob
>>
>>
>
>