Changes between Version 1 and Version 2 of DASISH/DiscussionPage
- Timestamp:
- 03/26/13 10:30:46 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DASISH/DiscussionPage
v1 v2 1 <Olof> In the examples in the specification document <targetSource> is in some 2 casesidentified by "xml:id" and also a "source" on page 7. Is there a1 **<Olof>** In the examples in the specification document <targetSource> is in some cases 2 identified by "xml:id" and also a "source" on page 7. Is there a 3 3 reason for having a temporary id as an xml:id and not the whole 4 4 uri+fragment in the relation reference?. … … 6 6 able to get the fragment containing the start/end for the annotation. 7 7 8 <Twan>I think indeed this could be solved without the xml:id; the source URI8 **<Twan>** I think indeed this could be solved without the xml:id; the source URI 9 9 should already be a unique ID. 10 10 11 <Menzo>Yes, and if the relation body is serialized in RDF it has to be URIs11 **<Menzo>** Yes, and if the relation body is serialized in RDF it has to be URIs 12 12 instead of IDs. 13 13 14 ---- 14 15 15 <Olof>I think we need to establish an XSD schema as soon as possible for the16 **<Olof>** I think we need to establish an XSD schema as soon as possible for the 16 17 representation of the serialized objects and a few close to real life 17 18 examples. This will be a good exercise for finalizing the exchange 18 19 format, for finding other issues and ideas for future improvements. 19 20 20 <Twan>Yes, I agree. Is this something we were going to do?21 **<Twan>** Yes, I agree. Is this something we were going to do? 21 22 22 <Menzo>Yes, I think the plan was that we would create more XML examples including23 **<Menzo>** Yes, I think the plan was that we would create more XML examples including 23 24 schemas. We didn't decide on a schema language ... unfortunately XSD is 24 25 still the prevalent one ;-) 25 26 26 27 <Olof>In the example (page 3) identification of the annotated node27 ---- 28 **<Olof>** In the example (page 3) identification of the annotated node 28 29 (start/end) is made by using xpointer (fid), Wired-Marker uses 29 hyperanchor <http://www.hyper-anchor.org/en/technical_format.html>and30 hyperanchor **<http://www.hyper-anchor.org/en/technical_format.html>** and 30 31 it works in a somewhat different way. Hyperanchor allows storage of 31 32 color etc. and requires less work effort and no changes in Wired-Marker. … … 33 34 conversion from hyperanchor to xpointer required for the client? 34 35 35 <Twan>I haven't looked into hyper anchor but I don't see why xpointer would be36 **<Twan>** I haven't looked into hyper anchor but I don't see why xpointer would be 36 37 a hard requirement as long as it does the job of reliably referencing a 37 38 fragment. I'm a bit worried about storing properties of the annotation 38 39 (such as colour) in the fragment identifier though. 39 40 40 <Menzo>I agree storing (some of) the annotation info in the fragment identifier41 **<Menzo>** I agree storing (some of) the annotation info in the fragment identifier 41 42 would be wrong. The fragments identifier should only contain information 42 43 to pinpoint a specific fragments in a source, not additional rendering or … … 53 54 identifier (Xpointer?)). 54 55 55 56 <Olof>When retrieving more than one source or annotation we need an wrapper,56 ---- 57 **<Olof>** When retrieving more than one source or annotation we need an wrapper, 57 58 this should be specified in the REST-specification. For ease this 58 59 wrapper should always be used, even if the result is one object. … … 67 68 of objects. 68 69 E.g.: 70 69 71 <result start="0" max="10" total="42"> 72 70 73 ... 74 71 75 </result> 72 76 73 <Twan>I think this is fine as well, I would propose to add it to the API77 **<Twan>** I think this is fine as well, I would propose to add it to the API 74 78 specifications like this. 75 79 76 <Menzo>Sounds good :-)80 **<Menzo>** Sounds good :-)
