- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Mon, 4 Feb 2013 09:55:05 +0000
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Paolo Ciccarese <paolo.ciccarese@gmail.com>, public-openannotation <public-openannotation@w3.org>
I agree that we can't risk just minting #tag URIs in someone elses namespace to try to work around the HTTP Range 14 problem. It would have to be some very unique tag so we know it's "ours" - like #ff3f6942-dc0d-484f-becb-b6eea4a1d6b3 - which would just be silly. I also of course agree that you "should not do that" - return a document for a "non-informational resource", but sadly the real world is our domain, and there is no specification now that mandates resources for "real world things/concepts" to NOT present representations. In fact it is core to the HTTP architecture that the Representation is distinct from the Resource. So - for your suggestion below: On Fri, Feb 1, 2013 at 6:31 PM, Robert Sanderson <azaroth42@gmail.com> wrote: > <anno1> a oa:Annotation ; > oa:hasBody <tagSpRes1> ; > oa:hasTarget <target1> . > > <tagSpRes1> a oa:SpecificResource , oa:[Semantic]Tag ; > oa:hasSource <http://omim.org/entry/104760> ; This is a beautiful solution. So am I right in assuming that you are suggesting that oa:[Semantic]Tag is a subclass of oa:SpecificResource (we would always use this pattern for semantic tagging), not just a suggested "rescue" pattern where you can't put http://omim.org/entry/104760 directly in oa:hasBody because it is (could be) a retrievable document? -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Monday, 4 February 2013 09:55:54 UTC