W3C home > Mailing lists > Public > public-openannotation@w3.org > April 2013

Re: Suggestions from iAnnotate Conference

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 24 Apr 2013 22:24:31 +0200
Message-ID: <51783F7F.6070602@few.vu.nl>
To: <public-openannotation@w3.org>
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
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
> 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
>
Received on Wednesday, 24 April 2013 20:25:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:04 UTC