RE: Adherence to standards vs specialized functionality

I have to admit that whenever I hear either “every resource has a global identity”, or “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” my head spins.  (Especially the “open world model” part.)

But concrete examples do make sense.

Thanks.

--Ray




From: Robert Sanderson [mailto:azaroth42@gmail.com]
Sent: Friday, July 10, 2015 5:48 PM
To: Denenberg, Ray
Cc: public-annotation@w3.org
Subject: Re: Adherence to standards vs specialized functionality


It's the same, really.  URIs globally identify the same resource, where ever you encounter that URI.  A URI in some annotation doesn't identify a different resource than the same URI in a different annotation.

So in the same way that assertions about the entities are of global scope, the identity of the entities are also of global scope.

R


On Fri, Jul 10, 2015 at 2:43 PM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
Thanks Rob.  You cited two principles:
*  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
And you’ve given a clear example, for the second, that relates directly to the subject at hand.   Can you give an example of the first?

Ray



From: Robert Sanderson [mailto:azaroth42@gmail.com<mailto:azaroth42@gmail.com>]
Sent: Friday, July 10, 2015 4:52 PM
To: Denenberg, Ray
Cc: public-annotation@w3.org<mailto:public-annotation@w3.org>
Subject: 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<http://example.org/anno1>",
"@type": "Annotation",
"target": {
  "@id": "example.org/logo.jpg<http://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<http://example.org/anno2>",
"@type": "Annotation",
"target": {
  "@id": "example.org/logo.jpg<http://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<http://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<mailto: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<mailto:azaroth42@gmail.com>]
Sent: Friday, July 10, 2015 3:22 PM
To: public-annotation@w3.org<mailto: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<mailto: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



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