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