Re: Last draft comment: Core

Hi Rob,



>> 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."


Perfect.

  
>
>> 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.


OK. To me "re-expressed as" meant more than "expressed at the same time as"; I was wondering whether there was some specific process being involved. But obviously that was much simpler :-)



>
>> 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.


I'm not so fond of relying only on PROV, because DC is much more used, and I've pointed in earlier messages that W3C specs do not shy away from re-using non-W3C elements. But anyway PROV is certainly relevant to the case, and I understand the point.

  
>> 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?


As per the other discussion: I'm not sure this negates any need. And whatever be the outcome of that other discussion, having oa:semanticTagging available in 2.3 shouldn't hurt that much.


> * Surely oa:semanticTagging skos:broader oa:tagging ?
>


Of course! Well spotted.

Antoine

Received on Monday, 4 February 2013 10:38:05 UTC