Re: Suggestions from iAnnotate Conference

Hello Samuel,

It's not dangerous to do it when it's needed and it's the appropriate grain. It's dangerous to strongly recommend it in the spec, because then readers could understand they have to do it even if they don't need it. And that would lead to unnecessary (many) statements.

I agree with the potential interoperability risk. But representing rights on (meta)data is not solely a matter for the annotation community. The rights interoperability problem is likely to happen for all kind of data. And while there is no widely accepted practice, it is dangerous indeed to tie the OA spec to a specific solution too much. Especially when many will regard this solution as super-verbose.

Best,

Antoine


> Hello Antoine,
>
> Can you give a more detailed example of why including dc:rights for
> each annotation is dangerous?
> Is there a case in which someone would not be able to describe the
> rights associated with each individual annotation?  If this is defined
> at the level of a dataset, it is simple to assign that right to every
> element in the set.
>
> However for anyone picking up a single annotation in some other
> compilation, if there isn't a uniform way to find the rights for that
> annotation, would be lost.
>
> SJ
>
>
> On Wed, Apr 24, 2013 at 4: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
>> 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 Thursday, 25 April 2013 07:41:42 UTC