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

Re: Sect 5.1 of future; Recommended JSON-LD context

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Mon, 28 Jan 2013 22:13:43 +0100
Message-ID: <5106EA07.4060307@few.vu.nl>
To: <public-openannotation@w3.org>
On 1/28/13 9:26 PM, Robert Sanderson wrote:
> On the logistics side, we don't currently have access to the namespace
> in the W3 site, although it has been reserved for us.
> This gives us two options:
>
> 1.  Use the W3C URI already, even though it's not actually there yet
> 2.  Use a different URI in www.openannotation.org (eg
> /spec/core/context-20130204.json) in the document, and when we do get
> the W3C URI then change it.  However, any annotations created with
> this temporary URI would be out of date before too long (I hope)
>
> I prefer option 1 as the context itself is given in the specification.


+1. Otherwise it seems you're just creating future trouble for everyone...

Antoine


>
> Also please, all, weigh in on Antoine's comment about the mapping for
> has[Class] predicates and oa:styleClass.
>
> Thanks!
>
> Rob
>
>
>
> On Mon, Jan 28, 2013 at 7:33 AM, James Smith<jgsmith@gmail.com>  wrote:
>> +1 for stable, versioned JSON-LD context documents
>>
>> Versioned contexts are useful when JSON-LD annotation data structures reference a context. If the context content changes, but the JSON-LD annotation data structure hasn't been updated to point to a different URL that holds the prior context that was used when building the JSON-LD data structure, then the JSON-LD might not represent the original annotation graph/concept/intent.
>>
>> So if we publish JSON-LD contexts for OA, we need to do so in a way that ensures they are stable so that people can reference them.
>>
>> A stable, versioned URL for a JSON-LD context is also useful when doing initial development/testing and you don't want to incorporate a full JSON-LD context processor into the application right away. Eventually, a proper JSON-LD application will need to process the context instead of keying off of the context URL.
>>
>> In some ways, the JSON-LD context can act like a namespace in XML, but it's more of a reference to a schema than a unique name. It's a mistake to treat the JSON-LD context as an XML namespace. As long as we're clear that we're not acting on the JSON-LD context URL as we would an XML namespace, I'm good with establishing well-defined, reference JSON-LD contexts for OA and what we might call OA application classes or modules.
>>
>> -- Jim
>>
>> On Jan 27, 2013, at 11:10 PM, Bob Morris<morris.bob@gmail.com>  wrote:
>>
>>> Yes, exactly.  I do note that in the Provenance section there is an
>>> Editor's note deferring modeling the version of OA itself.  That could
>>> apply to this too, but that's not clear to me.
>>>
>>> In the case of the serialization as JSON-LD, there is a need for a
>>> good contract between producer and consumer as to the actual
>>> @context. The spec itself is adequate to that, since the @context is
>>> listed in the spec, but whatever is arrived at for versioning the spec
>>> has the chance of needing to change that, hence change its name.  A
>>> scenario of slightly less importance is that as the OA spec itself may
>>> continue evolve toward its possible state as a W3 Recommendation,
>>> there are likely to be changes in the recommended @context.
>>>
>>>
>>> On Sun, Jan 27, 2013 at 7:48 PM, Robert Sanderson<azaroth42@gmail.com>  wrote:
>>>> Hi Bob,
>>>>
>>>> Do you mean a version in the URI so that systems "know" that they can
>>>> use their cached copy?
>>>> So:  .../context-20130128.json  to distinguish from any future version?
>>>>
>>>> Thanks!
>>>>
>>>> Rob
>>>>
>>>>
>>>> On Sun, Jan 27, 2013 at 1:44 PM, Bob Morris<morris.bob@gmail.com>  wrote:
>>>>> Sooner or later it might be good to assign a version to the
>>>>> recommended context document and/or some other way stable designation
>>>>> that does not depend on http dereferencing at  the time of
>>>>> serialization or deserialization.
>>>>>
>>>>> Bob
>>>>>
>>>>> --
>>>>> Robert A. Morris
>>>>>
>>>>> Emeritus Professor  of Computer Science
>>>>> UMASS-Boston
>>>>> 100 Morrissey Blvd
>>>>> Boston, MA 02125-3390
>>>>>
>>>>> IT Staff
>>>>> Filtered Push Project
>>>>> Harvard University Herbaria
>>>>> Harvard University
>>>>>
>>>>> email: morris.bob@gmail.com
>>>>> web: http://efg.cs.umb.edu/
>>>>> web: http://wiki.filteredpush.org
>>>>> http://www.cs.umb.edu/~ram
>>>>> ===
>>>>> The content of this communication is made entirely on my
>>>>> own behalf and in no way should be deemed to express
>>>>> official positions of The University of Massachusetts at Boston or
>>>>> Harvard University.
>>>>>
>>>
>>>
>>>
>>> --
>>> Robert A. Morris
>>>
>>> Emeritus Professor  of Computer Science
>>> UMASS-Boston
>>> 100 Morrissey Blvd
>>> Boston, MA 02125-3390
>>>
>>> IT Staff
>>> Filtered Push Project
>>> Harvard University Herbaria
>>> Harvard University
>>>
>>> email: morris.bob@gmail.com
>>> web: http://efg.cs.umb.edu/
>>> web: http://wiki.filteredpush.org
>>> http://www.cs.umb.edu/~ram
>>> ===
>>> The content of this communication is made entirely on my
>>> own behalf and in no way should be deemed to express
>>> official positions of The University of Massachusetts at Boston or
>>> Harvard University.
>>>
>>
>
Received on Monday, 28 January 2013 21:14:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 January 2013 21:14:13 GMT