Re: New Draft comments: Publishing

>> 1. Names in JSON serialization specification
>> This has probably been discussed before I joined the group. But why are the
>> names "body", "target", ..., "scope" not exactly following the labels of OA
>> properties (oa:hasBody, oa:hasTarget, etc) just like all other names in the
>> JSON serialization spec?
>
> This was just to be more "JSON-friendly" rather than a strict 1:1
> mapping into RDF.  The expectation was that developers wanting a JSON
> serialization which happens to be RDF would be more comfortable with
> these object/hash property names.
>
> This doesn't quite work with the provenance predicates any more, but
> they're at least not of the format "hasClass".
>
> I'm pretty certain that no one has implemented this yet (other than
> me), so we can go back the other way and have a strict name mapping.
> The change would be to reintroduce the "has" for those predicates and
> to map oa:styleClass to "styleClass" instead of "style".


Yep, I had missed this one.
I think that here the benefits of homogeneity (for understanding the spec and for maintaining it) are too big to ignore. In fact if members of the group feel the properties should be JSON-friendly, then I'd rather have the RDF properties JSON-friendly, too!

  
>> 2. The paragraph on embedding RDF graphs in 5.2 ("An unusual [...]
>> serialized resource") could be quite confusing. Especially, it reads a bit
>> out of synch with 5.4, which recommends using named graphs.
>
> I agree that paragraph is confusing and that 5.4 isn't clearly
> structured.  The intent, which I will fix, is:
>
> * SHOULD just refer to a dereferencable HTTP URI for the graph
> * if the graph is embedded:
>     * SHOULD use Content in RDF
>     * MAY use Named Graphs IFF trig/trix is requested with content negotiation


Are we sure we want to express a preference here (SHOULD vs. MAY) between Content in RDF and NGs? I personally think we could keep them on a par -- though I won't be fighting for it till death.


>> I'd suggest:
[...]
>
> Will fix.


Great!



>> 3. Is oa:equivalentTo transitive?
>
> I believe so.  If A equiv B, and B equiv C, then A equiv C.
> (and C equiv B, and C equiv A, and B equiv A)


OK, then I think it's worth being mentioned. It always help (at least people like me) to get the intended semantics.

  
>> 4. Is oa:equivalentTo meant to be used only for oa:Annotations?
>
> No, it could also be used productively for embedded resources.  The
> use case would be if two systems extract and republish an embedded
> resource, they would give it different HTTP URIs.  However if both
> asserted that the new URI was equivalent to the original's UUID, then
> given the transitivity above, a further system could determine that
> all three identifiers were related to the same content.
>
>> *If yes* is it mappable to ore:similarTo [1]? This would relate to my very
>> last comment on
>> http://lists.w3.org/Archives/Public/public-openannotation/2013Jan/0044.html
>> which I think was not really answered.
>
> Sorry! Will go back to that :)
>
>> Now that the spec has has been (rightly so) shifted to make oa:Annotation a
>> more conceptual, less serialization-focused notion, it could be harmful to
>> have it likened to an ORE Aggregation.
>
> The intent of ore:similarTo was to link to other identifiers for the
> "work" that are not identifiers for the aggregation.
> For example a particular aggregation of PDF, plus DOC plus a dataset
> and an experiment could be ore:similarTo a DOI that identifies (cough,
> handwave, mumble) a journal article.
>
> I think that equivalentTo is a stronger statement than that level of
> similarity, but we get close to ontology in the philosophical sense of
> the word.  If every plank/URI of a ship/Annotation is replaced, is it
> still the same/equivalent ship/Annotation?
>
> The intent of equivalentTo is to help federating systems to determine
> that two Annotations are similar enough that only one needs to be
> maintained or processed.  That even though they have different URIs,
> they express the same concept and hence should not both be rendered to
> a user, processed for reputation models, or even take up space on
> disk.
>
> Technically, the domain of ore:similarTo is ore:Aggregation.  Which
> would then have reasoners assume that the Annotation is an
> Aggregation. Which doesn't work
>
> I can strengthen the discussion of equivalentTo in this way if that would help?



Yes, even though maybe you don't need to write all this ;-)
In fact the first argument was good enough for me: if oa:equivalentTo can be used for bodies, then it is dangerous to use ore:similarTo instead (since its domain is ore:Aggregation and I don't think I like having bodies or targets instances of ore:Aggregation).

Cheers,

Antoine

Received on Monday, 28 January 2013 21:46:23 UTC