Re: Adherence to standards vs specialized functionality

Thanks for the framing, Ray!

The primary issue is that you cannot, using RDF, make assertions about a
resource that are only true within the context of a single annotation, and
not true in other annotations.

For example, you cannot say that an image has a segment, like this:

{
"@id": "example.org/anno1",
"@type": "Annotation",
"target": {
  "@id": "example.org/logo.jpg",
  "hasSegment": "xywh=0,0,100,100"
}

Because that segment is only true for the target of that particular
annotation.  Another annotation might annotate the same image with a
different segment:

{
"@id": "example.org/anno2",
"@type": "Annotation",
"target": {
  "@id": "example.org/logo.jpg",
  "hasSegment": "xywh=512,512,100,100"
}

In the Linked Data view of the world, this is the same as saying

{
  "@id": "example.org/logo.jpg",
  "hasSegment": ["xywh=0,0,100,100", "xywh=512,512,100,100"]
}

because where the `logo hasSegment "string"` assertion is made does not
matter.  It is not, in any way, dependent on or even related to the
Annotation.

I quote my objections to the specific issue below to be considered in light
of the above.

And secondly, the solution is already present in the model -- the
SpecificResource construction.  The SpecificResource node is the way to
avoid making assertions about things that are likely to be reused.  It
allows the exact nature of the body/target to be described without directly
making assertions about the body/target resource.  There are other patterns
that would also work, but that is the way the CG decided on (I can go into
reasons if desired).  Thus, to allow the role to be associated with part of
a video there would be a Specific Resource that had the role, a selector to
describe the appropriate part of the video, and a reference to the video
itself.  There is a single line change ... allow motivatedBy on
SpecificResource ... or there are alternatives that break fundamentals of
the web architecture and RDF, are more complex to process for everyone,
aren't fit for purpose because they only address a small subset of the
problem, and make interoperability between systems significantly harder by
obscuring the basic assertions of the model such as which resource is the
body and which the target.

I'm also happy to have others more intimately familiar with RDF and Linked
Data than me check over the logic. I would suggest David Wood, as an
implementer of Open Annotation, LDP and co-chair of the RDF WG, and thus
perfectly positioned to confirm this position or point out any inaccuracies.

Rob


* If we allow role on EmbeddedContent, it ties the EmbeddedContent resource
explicitly to the Annotation.  That's a restriction that we have not had in
the past, and I question the cost/value of doing so, as it is only needed
in the multiple body scenario, which is the 1% case not the 99%.  On the
other hand that is the intent of the SpecificResource... A more specific,
constrained version of the body or target resource, based on annotation
specific requirements.

* If a server mints a URI for the EmbeddedContent resource, which would be
the best practice according to Linked Data [avoid blank nodes if possible,
use HTTP URIs to name things], it would very much like the Resource Body
pattern and we would be inconsistent after the initial client POST to the
server.

* If a further annotator selects part of the text of an EmbeddedContent
resource (eg to suggest an edit), then the body of one annotation is now
the target of another.  But would still carry the role from when it was the
body, in a different annotation where that role is completely wrong. By
trying to make it easier, we've prevented what I think should be a valid
use case, because the embedded resource is tied exclusively to the
annotation in which it is the body.

* There would be at least *five* different ways to express the basic
requirement of a role for a simple, embedded text body:
1.  Annotation with a motivation and ...
    1a.  body as literal
    1b.  body as EmbeddedContent
2.  Body as EmbeddedContent with role/motivation
3.  Body as SpecificResource with ...
    3a. source as EmbeddedContent with a role/motivation
    3b. role on the SpecificResource, and source as EmbeddedContent without
a role/motivation

I seriously question whether this is *less* complex than having a single,
clear requirement that everyone implements.  In the proposed solution,
every client implementer will need to check all of those scenarios for
every annotation. I strongly disagree that requiring such checks would be
easier than always looking in the same place in a consistent structure.  So
exactly who are we helping with this? Not the client developer, and not the
server developer.  Not the user, as they never see this level anyway.

* The distinction between Tags and SemanticTags becomes even weirder.  If
we introduce some method for per-body roles we could do away with the
unloved Tag/SemanticTag classes... but only if the role is associated with
the SpecificResource, for the same reasons we removed the recommendation to
add the SemanticTag class to arbitrary URIs [global assertions, and all
that].  Again, consistency has a value of its own, far beyond theoretical
purity.



On Fri, Jul 10, 2015 at 12:44 PM, Denenberg, Ray <rden@loc.gov> wrote:

> Well then let me rephrase the question, in an attempt to avoid trying to
> make sense of the near-hundred email on this, and try to get to the heart
> of the issue: What is being suggested that violates these principles, and
> more importantly, how do they violate them?  (Maybe it would be good if, in
> preparation for a conference call on this, we could take a fresh look, and
> start by framing the issue.)
>
>
>
> Ray
>
>
>
> *From:* Robert Sanderson [mailto:azaroth42@gmail.com]
> *Sent:* Friday, July 10, 2015 3:22 PM
> *To:* public-annotation@w3.org
> *Cc:* W3C Public Annotation List
> *Subject:* Adherence to standards vs specialized functionality
>
>
>
>
>
> The principles are pretty fundamental:
>
>
>
> *  one from the web architecture, that every resource has a global identity
>
> *  and one from RDF, that the graph is an open world model where the
> context of an assertion has no bearing on its scope: all assertions are of
> global scope
>
>
>
> If we're going to ignore fundamentals like those, we should stop and
> reassess the value of all existing work because we would be making
> tradeoffs at the edges that break the core.  If we're going to make such
> tradeoffs, then we should do it from the core out not the edges in.  That
> would mean, essentially, starting again.
>
>
>
> Consider the agony of dealing with badly formed HTML and having to guess
> at the intent of the author, compared to well-formed XML. There's a cost at
> creation time to adhere to the specifications, but it makes everything much
> easier down the line.  I sure hope we're past the stage of wanting to
> define the equivalent of kludgey, sloppy HTML.
>
>
>
> Rob
>
>
>
> On Fri, Jul 10, 2015 at 11:50 AM, Denenberg, Ray <rden@loc.gov> wrote:
>
> From: Doug Schepers
> > Regarding assumptions, for example, there seems to be an implicit
> assumption
> > that we need to prioritize adherence to the RDF model over performance or
> > specialized functionality;
>
> Doug - what would be the RDF model principles relevant to this issue?
>
> Ray
>
>
>
>
>
>
>
> --
>
> Rob Sanderson
>
> Information Standards Advocate
>
> Digital Library Systems and Services
>
> Stanford, CA 94305
>



-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305