Re: Review of future/core.html

>
>
> Summary:
>
> This reads very well! The specification is beautiful. I am getting
> prouder and prouder of the high quality of this specification, and I
> am getting such feedback from others as well.
>

That is good to hear :)


>
> Below I have clarified a few terminology things, some technical tweaks
> for examples, some relaxation on fragmentation URIs for semantic
> resources, and clarification on what the provenance terms are to be
> used on.
>
>
>
> First of all - I think the splitting into levels and getting rid of
> the OAX spec is a great improvement. Good job!
>
> > http://www.openannotation.org/spec/future/
>
> 1) This Version link and Previous Version link and text are wrong.
> (Can we please try to get these right..? Those links are most
> important to exactly this group)
>

That is related to the nature of the document 'future' as it evolved in
time.
Once we have agreement, it will be moved to the right ___location and the
links will be updated.
But probably "previous version" could be updated already.


>
>
> 2) The document is split into several HTML pages, but there is no
> obvious link to section 2 etc. from the bottom of the front page -
> it's not very obvious where to go next.  Propose "previous   contents
>  next" links for top *and* bottom of every page - however the index
> page only needs it at the bottom.
>

That is a good suggestion indeed!
I often found myself going back to the TOC for jumping to the next document.


>
>
> > http://www.openannotation.org/spec/future/core.html#BodyTarget
>
> 3) "The Body and Target MAY be of any media type" - I would change
> this to lower-case "may" - or are you suggesting there are cases when
> they are not of any media type?
>

'can be'?


>
>
> 4) "See Further Examples" links don't work.
>

They are not yet existing :)


>
>
> http://www.openannotation.org/spec/future/core.html#BodyEmbed
>
>  5)   dc:format "mimetype1" .
>
> "mimetype1" is not a valid type. Change example to an actual mime type,
> like:
>
>    dc:format "text/plain" .
>

All the examples are abstract. mimetype1 is a placeholder for any
applicable mime type.
In that specific example, it could be "text/plain", "text/html"...

Besides leaving as it is, I see two other ways:
a) change it to one text type as you suggest and specifying in a note that
that is one possible applicable mime type.
b) without specifying one format we could change 'mimetype1' into
'textmimetype' and then add the note about text mime types.

I am in favor or your suggestion (a) plus the note.



>
>
> > If known, the MIME type of the text SHOULD be given using the dc:format
> property
>
> 6) The 'correct' term is "media type", and the link should rather go
> to http://www.iana.org/assignments/media-types - "mime type" is also
> mentioned later in this page, seach-replace to media type.
>
> (I know we should 'really' be using dct:format to formally say this is
> a media type. dc:format also allows physical formats like "brochure"
> and "political poster" -
> http://dublincore.org/documents/1998/10/23/format-element/  -- However
> dct:format becomes a bit more verbose: https://gist.github.com/4635250
> - I use the second form, but would not be pushing for this here.)
>

+1 for 'media type'


>
>
>
> > Most fragments are defined with respect to individual MIME types, and
> not every MIME type has a fragment specification.
> > Even if a MIME type does have a fragment definition, it is often not
> possible to describe the segment of interest sufficiently precisely. For
> example, fragments for HTML cannot be used to describe an arbitrary range
> of text.
>
> 9) As above, "MIME type" -> "media type"
>

+1

Paolo