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> 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]
> *Sent:* Friday, July 10, 2015 4:52 PM
> *To:* Denenberg, Ray
> *Cc:* 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",
>
> "@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
>



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