Re: Review of future/core.html

On Sun, Jan 27, 2013 at 7:35 PM, Stian Soiland-Reyes
<soiland-reyes@cs.manchester.ac.uk> wrote:

> BTW - which of the annotation tools could be good for doing exactly
> this kind of email and review? :)

Indeed! We should eat our own dogfood as soon as possible :)
As Laela says, it's hard to even track the discussions without
spending a lot of time on it.  That does mean that there are valuable
and informed discussions going on though, which is hugely important
and a good sign that things are going well.

> 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's fantastic, many thanks Stian :)


>> http://www.openannotation.org/spec/future/
>
> 1) This Version link and Previous Version link and text are wrong.

Yes, they'll be fixed when it goes into its real home.

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

Fixed.


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

Heh. Indeed, the MUST be of some media type, but neither are useful statements.
Fixed.


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

Will work in final home, and once the spec is fixed so we can work on them :)


>  5)   dc:format "mimetype1" .
> "mimetype1" is not a valid type. Change example to an actual mime type, like:
>    dc:format "text/plain" .

Yes, this is the abstract versus concrete example issue in the same
way as the headers literal.

How about, for consistency, if literals are concrete examples, but the
nodes remain identified only as they are now.
So <spec1> and <target1>, but "text/plain" and 4096.

I'll do this throughout by the end of the day.


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

Fixed.


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

Yes, indeed :(  The perfect being the enemy of the good, in this case.

>>  <body1> a cnt:ContentAsText, dctypes:Text ;
>>    cnt:chars "content1" ;
> 7) Could I suggest :body1  as the identifier here instead of <body> to
> indicate that the URIs for embedded bodies typically would be
> non-resolvable?

The double lines indicate non-resolvability.  I think that the UUID
URN case (which is the recommended approach) warrants the <>s rather
than the blank node implying :
This would mean changing many of the examples and section 1.4 ...
which we can do of course, but I wonder if its valuable?


>> Query: Find all of the annotations with embedded, textual comments.
> 8) Could I suggest to change it to "find all textual comments" ? It is
> slightly more realistic, and should make it easier to see that this is
> not a particularly tricky model.
>
>  SELECT ?comment WHERE {
>     ?anno oa:hasBody ?body .
>     ?body a dctypes:Text ;
>         cnt:chars ?comment }

Sure, great suggestion. Fixed.

>> Fragment URIs Identifying Body or Target
>> It is not possible to determine with certainty what is being identified, as the same fragment string might be possible in different specifications. For example, the same fragment could identify either a semantic resource in RDFa or a section of the HTML document.

> 10) RDF 1.1 will however clarify this:
> http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#section-fragID

True, it clarifies that particular case. A poor example ... but at
least one that many people understand, and hence is being resolved.
I've clarified that you cannot tell what is being identified /without
knowing the media type/.


> 11) This section should clarify that semantic terms, such as semantic
> tags with oa:Tag would often be in the form of fragment URIs, but as
> this is not for the purpose of selecting a part of a resource, but
> identifying a concept, such URIs are perfectly OK and SHOULD NOT be
> specified using a Selector.

Fixed, and used MUST NOT.
I do hope that no one mints a semantic tag URI like
http://example.com/tags#xywh=1,1,1,1   :)

> In addition, a resource containing oa:Annotation's might be using such
> fragment URIs instead of bnodes to identify embedded textual bodies
> and other elements of OA such as agents.
>
>  <http://www.example.com/anno1> a oa:Annotation ;
>     oa:hasBody :body1 ;
>     oa:hasTarget <target1> .
> <http://www.example.com/anno1#body1> a cnt:ContentAsText, dctypes:Text ;
>     cnt:chars "content1" ;
>     dc:format "mimetype1" .

Mmmrph. Yes. Unless it's in RDF/XML, as then #body1 would identify an
XML element, as per the previous issue.
Or in whichever serialization uses text/plain (n3?) and then it could
collide with RFC 5147.  :(

Do we need to mention this explicitly?  This seems like a can of worms
best avoided by pointing at the UUID or blank node recommendation.

>> 2.2 Annotation provenance
>> It is important to note that the provenance information applies only to the Annotation, and not necessarily the Body, Target or any other resource in the Annotation graph. Provenance information may also be attached to those resources separately.
>
> 12) This sounds contradicting, the provenance information applies only
> to the Annotation, but can be attached to body and target separately?
> I think we need to clarify the two things separately - what can we
> attach Provenance information to (Annotation, Body, Target, and other
> resources), and what is the scope of the provenance model we make
> here. I suggest:

Fixed. That was indeed the intent -- the wording was carried over from
when the same properties (dc:creator etc) could be used on both, and
thus the confusion.


> 13) As the model below only works on oa:Annotation, I would clarify
> add something like:
>
>> It is considered out of scope for this specification to model provenance at such an abstraction level, as existing vocabularies such as [DCTerms] and [PAV2] give sufficient coverage. However for convenience a minimal model for specifying provenance of the Annotation is provided below:

Fixed.

> Re PAV - Me and Paolo are preparing to release PAV 2.1 at
> http://purl.org/pav before end of month (I'll try to squeeze it in
> today!) - it includes PROV bindings and HTML view of the ontology, and
> would easily do the Darwin example.

Let me know when this is available and I'll link it in the specification.


>> " The datetime MUST be expressed in ISO 8601 format." - this is very vague, if you read ISO 8601 you will understand.  Is "2009-W53-7" ok?

True.

> 14) I think this (occurs twice) should be:
>> The datetime MUST be expressed in xsd:dateTime (ISO 8601 extended date time) format:  [http://www.w3.org/TR/xmlschema-2/#dateTime ] and SHOULD have time zone specified.

Fixed.


> 15) Well, let's at least practice what we preach!
> This should be:
>>     oa:annotatedAt "2005-12-24T03:18:56-0500"^^xsd:dateTime ;
>>     oa:serializedAt "2013-01-28T02:24:56Z"^^xsd:dateTime .

With the explicit datatype?  We don't recommend/use explicit datatypes
elsewhere.

Rob

Received on Monday, 28 January 2013 19:00:44 UTC