Re: Streamlining the OA Model

On Tue, Jul 31, 2012 at 10:32 AM, Paolo Ciccarese
<paolo.ciccarese@gmail.com> wrote:
>
>
> On Tue, Jul 31, 2012 at 1:01 PM, James Smith <jgsmith@gmail.com> wrote:
>>
>>
>> On Jul 31, 2012, at 12:02 PM, Bernhard Haslhofer
>> <bernhard.haslhofer@cornell.edu> wrote:
>>
>> > 1.) Direct Relationship between Annotation and the Source
>> >
>> > "Give me all annotations for resource X", is probably one of the most
>> > important queries that needs to be answered. X could be an image URI, the
>> > URI of a video, whatever. Since the the Target of an annotation may be a
>> > resource with its own dereferencable URI OR a Specific Target with a UUID
>> > node, you need to consider this when formulating a query and end up with a
>> > SPARQL UNION query or some conditional node traversal code when using an RDF
>> > API.
>> >
>> > Technically, it is of course possible to do that, but given the
>> > importance of that query, I would argue that the solution is not very
>> > intuitive and maybe also not very efficient. I believe that this can easily
>> > be be fixed by introducing a direct relationship property (e.g.,
>> > oa:annotates, oa:hasTargetSource) between the Annotation and the Source
>> > resource.
>> >

<snip>

>
> I am also wondering if this topic is related somehow to 'annotating an image
> within a HTML document', in other words annotating an image keeping track of
> the fact that annotation is valid when the image is displayed in a specific
> document. In such case, what ao:annotates would point to? The image -
> knowing that the annotation is validfor the image in a specific context - or
> the HTML page - that contains the image?
>

I think we should explore Paulo's question more. Does this help
clarify context somehow?
Creating oa:annotates on the Annotation is great for the simple cases,
but falls apart for more complicated cases and therefore actually
exacerbates the query complexity by creating a new case.

>
>
>>
>>
>> > 2.) Fragment URIs as Targets
>> >

< snip>

>> > The Open Annotation model currently does NOT RECOMMEND the use of
>> > fragment URIs for identifying segments of Targets or Bodies for three
>> > reasons (see 5.2.1):
>> >
>> > - "cannot query the source directly": I think this could and should be
>> > solved by considering (1.)
>> > - "they are not compatible with State and Style Specifiers; many
>> > annotations may have the same segment of interest, but have different States
>> > and Styles": from previous emails and discussions I understood that Styles
>> > should be directly attached to the Annotation, which also means that that
>> > they are contextualized and not an argument against fragment URIs anymore. I
>> > think that sth. similar can be done with "State" and would also result in a
>> > more consistent model and allow for fragment URIs
>> > - "Fragment URIs conflate the identity and the description of the
>> > segment of interest by including the description inline within the
>> > identity": I am not sure if I get the point of this argument right; however,
>> > I believe that for very practical reasons the OA model should reuse what
>> > other specifications (Web Architecture, Media Fragment RFCs) already define;
>> > this brings modularity and flexibility and avoids the risk of re-designing
>> > what others already did elsewhere.
>> >
>> > I think the benefits of reusing (Media) Fragment URIs in OA prevail the
>> > arguments of not using them and therefore I propose to RECOMMEND the use of
>> > Fragment URIs and only fall-back on OA-specific Selectors if Fragment URIs
>> > are not expressive enough.
>>
>> -1 from me for this. URIs are opaque. They have no semantics in the
>> context of RDF. Clients should only have to use them as part of a protocol
>> request (e.g., an HTTP GET).
>>
>> What OA does is break the URI+Fragment into two pieces: the URI, which can
>> be dereferenced, and the Fragment, which the client can parse and use. The
>> target is broken into a server component and a client component, since the
>> server should never see a fragment identifier, and the client should never
>> parse the URI. Putting the two together requires the client to parse the URI
>> and the server to know that it has to ignore anything in the URI that
>> follows the hash (#). This could break some servers (testing required, but
>> servers don't see a hash+Fragment from browsers, so they might be designed
>> not to expect it).
>

I absolutely see value in separating the components. I believe I'd
like to see the current recommendation taken away and replaced with a
suggestion that if URIs with a fragment are used as a target the agent
should assert a hasSource triple to link it to the URI without the
fragment.

Of interest here is probably this document:
http://www.w3.org/TR/fragid-best-practices/
"First Public Working Draft" as of last week.

Fragments are a nice feature of URIs. I think we should embrace them
with a strong recommendation for including hasSource. Although, the
hasSource can actually be inferred upon ingestion. It seems
unnecessary to me to recommend against using them.

>> > 3.) Simple Literal Body Shortcut
>> >
>> > I understand that an OA annotation is a relationship between resources
>> > (the body and the target) and that inline bodies are represented using the
>> > Content in RDF specification (see 6.1.). However, our own demonstrator and
>> > also the majority of use cases demonstrated in the OAC meeting last week
>> > showed that many annotation bodies are simply strings, which could be
>> > represented as literals.
>> >
>> > Therefore I am proposing to introduce a "shortcut" property between the
>> > Annotation and the "content" Literal (e.g., hasLiteralBody). This allows
>> > people to express simple annotations in a, in my opinion, more
>> > straightforward way and doesn't contradict the current oa:hasBody approach.
>> >
>>
>> -1 from me. I don't see how this isn't a premature optimization. The
>> examples at the OAC meeting used the simplest possible body, so I don't
>> expect them to be representative of usage "in the wild." With more data from
>> live, publicly available projects where the optimization represents a
>> significant gain, I might be persuaded otherwise.

+0. I find the representation convenient for parsing with my human
eyes, but also recognize that I'm not necessarily going to use a
triple store anyway. Adding these the content in rdf triples on the
way out is a one time programming cost.

>>
>> > 4.) Style Attached directly to the Annotation
>> >
>> > We don't express style information in our serializations because I
>> > believe that styling information and data representation should be
>> > separated. However, I understand that there are use cases that require this
>> > feature and I prefer the approach of optionally attaching style directly to
>> > the annotation over attaching it to the Specific Target.
>> >
>>
>> +1 from me. I think it makes more sense for the style to affect the
>> annotation than the target.

+1 as well. There's some things to work out. We should create examples.

>>
>>
>> > 5.) JSON (-LD) Serialization Recommendation
>> >
>> > At the moment the spec recommends that RDF/XML is used as default
>> > serialization language. We haven't implemented it yet, but I'd consider JSON
>> > (-LD) at least as alternate "default" serialization format to open the door
>> > for JS clients.
>>
>> I'm on the fence with this. I definitely think JSON is outgrowing XML as a
>> serialization standard on the web. JSON is designed for data structures. XML
>> is designed for documents. RDF is more a data structure than a document. Any
>> JavaScript libraries I produce will work with RDF/JSON and let the user add
>> in any RDF/XML support they might need. My server implementations will
>> produce RDF/JSON and probably RDF/XML (one is easy once you have the other).
>> In my own shared canvas work recently, I'm producing RDF as JSON, XML, and
>> Turtle, as well as a HATEOAS-oriented JSON. In the world of linked data and
>> REST, the important thing for OA is the data model, not the serialization
>> format.

I don't think a recommendation for any serialization is necessary.
We should definitely provide examples, though. I've got the demo I
gave cleaned up to the point of completion. I will get it on the wiki
this week.

-Randall

Received on Tuesday, 31 July 2012 18:47:22 UTC