W3C home > Mailing lists > Public > public-annotation@w3.org > August 2015

Re: [model] Clarifying annotation architecture

From: Randall Leeds <randall@bleeds.info>
Date: Tue, 04 Aug 2015 17:58:49 +0000
Message-ID: <CAAL6JQgGxeoRK-4ydAt0pYHGikjA7HkKJL6_zZsoR+e54bP6mw@mail.gmail.com>
To: Robert Sanderson <azaroth42@gmail.com>, Ivan Herman <ivan@w3.org>
Cc: Frederick Hirsch <w3c@fjhirsch.com>, Tim Cole <t-cole3@illinois.edu>, W3C Public Annotation List <public-annotation@w3.org>
If a system consumes an annotation with blank nodes and subsequently
assigns then URIs, I don't see a problem.

A different system that does the same will assign its own URIs, and so
there is no conflict, there are now two different resources that duplicate
the content, each can be the subject of statements independently.

A system that wishes to annotate these resources would use the typical
SpecificResource construction to avoid making open world statements about
the originals.

So, I see no problem at all with using blank nodes for the bodies as in
Tim's example. In practice, I imagine that annotations with blank nodes
might acquire URIs as they are shared and reproduced, but so what?

The worst case scenario is that two independent consumers assign different
URIs, then subsequent statements about these have their relationship
obscured.

That's maybe really not so bad.

Yet the construction is much simpler and elegant for the producer.

Anyway, isn't part of the purpose of an annotation data model to capture
references not a priori uniquely identified by the publisher? If we really
want to make a statement about a blank node, maybe the right move is to
select it out of some more canonical reference? GraphPathSelector anyone? ;)

On Tue, Aug 4, 2015, 10:44 Robert Sanderson <azaroth42@gmail.com> wrote:

>
> Hi Ivan,
>
>> I am not sure why a URI must be assigned to a blank node body. However,
>>> it indeed it must, then (just as in any other RDF environment) I believe it
>>> is a requirement that URI-s assigned to a body must be unique.
>>
>>
>> It doesn't have to be, but some systems will just do it for you.  The
>> best practices of linked data are to avoid blank nodes, after all.
>>
>> Yeah, well, I do not think we should be religious about it. In my view,
>> using blank nodes for the situations we are discussing here is perfectly
>> fine.
>>
>
> Indeed, but we shouldn't prevent other people from being religious about
> it :)
>
> The use case I gave earlier was if you want to annotate the body and
>> particularly if you're using a selector, it needs a URI to be the target of
>> the second annotation.  You can't target the annotation and mean the body,
>> as it would be ambiguous in the case we're discussing of multiple bodies.
>>
>> I am lost. I think Tim's example was for the resources used as an
>> encapsulation for the body and a motivation. That one does not really need
>> its own URI. That is where blank nodes are perfectly fine.
>>
>
> They're fine until someone wants to reuse it when it does get its own
> URI.  Blank nodes are still resources.
>
> I do not understand what you mean here. My only comment was to say is that
>> if the system chooses to provide a URI to blank nodes (ie, it skolemizes
>> the blank nodes), we can safely assume and even require that the resulting
>> URI-s will be different for different blank nodes.
>>
>
> They'll be different URIs, sure, but that doesn't mean that they're
> reusable.  If the motivation is associated with the body directly, then it
> cannot be reused in another annotation. You couldn't target the body to
> comment about a spelling mistake. There would be different models for blank
> node resources and resources where those blank nodes have been assigned a
> URI.  That then means understanding why there are two models... and we're
> back to the same situation... except it's more likely that people will do
> it incorrectly by inferring from the blank node case that the same will
> work with URIs.
>
> Rob
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>
Received on Tuesday, 4 August 2015 17:59:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC