Re: Last draft comment: Core

On Sun, Feb 3, 2013 at 12:47 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> 1. Presentation of Dublin Core Type classes being re-used in 2.1.1
> "The most common classes are listed in the table below" seems to be
> contradicted by the heading for that table, "Model". Unless the intention is
> to re-used *only* these classes, in which case it should be made explicit in
> the text.

Missed this one, sorry!
Clarified by adding:
" but other classes MAY also be used."


> 2. In 2.1.3, what does "As such, these resources MUST NOT be re-expressed
> using FragmentSelectors" mean?

This was from Stian, that you MUST NOT re-express fragments with a
fragment selector if they don't define a segmentation of the
representation.

For example annotating the hypothetical
http://public.lanl.gov/rsanderson/rdf#me MUST NOT be reexpressed as

_:sr1 a oa:SpecificResource ;
  oa:hasSource <http://public.lanl.gov/rsanderson/rdf> ;
  oa:hasSelector _:fs1 .
_:fs1 a oa:FragmentSelector ;
  rdf:value "me" .

I tweaked the wording to hopefully be clearer.

> 3. In Fig. 2.1.3.2
>  oa:hasTarget <target1>.;
> ->  oa:hasTarget <target1> .

Good eyes! Thank you!


> 4. Mapping to Dublin Core in 2.2
> In an earlier version oa:annotatedBy (resp. oa:annotatedAt, oa:serializedBy)
> was mapped to dcterms:creator (resp. dcterms:created, dcterms:publisher. I'm
> not sure why these mappings were removed, as they seem quite right and the
> mapping to PROV does not really replace them.

The decision was to remove them, I don't recall the exact rationale,
other than to try to stick more closely to W3C standards where ever
possible, and to not confuse the matter by having multiple mappings.


> 5. Relation between  oa:semanticTagging and oa:tagging in 2.3

> I support Stian's interrogation (and his implicit proposal) at
> http://lists.w3.org/Archives/Public/public-openannotation/2013Feb/0002.html
> "oa:semanticTagging is skos:narrowerThan (?) oa:tagging"
> The spec should reflect that
> oa:semanticTagging skos:narrower oa:tagging
> otherwise it may be difficult to convince implementers to create semantic
> relations for their motivation extensions.

Sure. The more broadly usable motivations with clear use cases in the
spec rather than having to be defined elsewhere, the better.

Two points:
* Does this negate the need for oa:SemanticTag vs oa:Tag?
* Surely oa:semanticTagging skos:broader oa:tagging ?

Rob

Received on Monday, 4 February 2013 00:47:40 UTC