- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 05 Dec 2013 10:48:41 -0500
- To: public-lod@w3.org
- Message-ID: <52A0A059.4010109@openlinksw.com>
On 12/5/13 8:52 AM, Thomas Steiner wrote: > Dear Public-LOD, > > Thank you all for your very helpful replies. Following your joint > arguments, owl:sameAs is _not_ an option then. The most reasonable > thing to do seems to introduce some sort of proxy object, on top of > which statements can be made. > > One idea that came to my mind (and I am not yet sure if it is stupid > or genius) would be to use the <video> element itself as the proxy > object. Rather than making statements about the concrete encodings > (i.e., the .mp4 and the .ogv), would it make sense to make statements > using the "container" that holds them? Assuming the following Web page > located at http://videos.example.org/ with a <video> element with an > ID… > > ======http://videos.example.org/====== > <video id="video"> > <source src="./video.ogv" type="…"> > <source src="./video.mp4" type="…"> > </video> > =============================== > > …this would allow me to say… > > <http://videos.example.org/#video> a ma:MediaResource . > <http://videos.example.org/#video> ma:title "Sample Video" . > <http://videos.example.org/#video> ma:description "Sample Description" . > <http://videos.example.org/#video> ma:locator <http://ex.org/video.mp4> . > <http://videos.example.org/#video> ma:locator <http://ex.org/video.ogv> . > > Regarding the ma:MediaResource, the Media Ontology seems to support > this: http://www.w3.org/TR/mediaont-10/#media-resource. > > Does this make any sense at all? Yes. > What do you think? Just fine :-) > > Thanks, > Tom > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 5 December 2013 15:49:04 UTC