- From: Gannon Dick <gannon_dick@yahoo.com>
- Date: Mon, 22 Feb 2010 12:37:58 -0800 (PST)
- To: public-egov-ig@w3.org
- Cc: Mike Thacker <mike.thacker@esd.org.uk>, VassiliosPeristeras <vassilios.peristeras@deri.org>, Chris Beer <chris-beer@grapevine.net.au>
Chris et. al.
'Mike raises another good point which is also a concern with me btw - "do
we have a definition of service".'
This is part of a larger education problem with meta data. Most people think you can choose names and content according to whim. Actually you can choose either, but not both. Tabular data (web form submissions, Address Books, etc.) are a much harder problem since the nominal format ("Data View") contains no formal meta data repository.
see: http://www.rustprivacy.org/meta/roundtripping.pdf
Fortunately, HTML documents have a meta property list, one D, but you can work with it. I am not sure you need a definition of a "service" as it is just another resource (under some constrained circumstances). I approached the problem from a little different perspective: What do you need for an end-to-end (Word Processor to Catalog) archive process ?
The OpenOffice XHTML export uses Dublin Core linking syntax, as does AGLS. The XSLT is (nymg.xsl) "Not Yo Mama's GRDDL".
example: http://www.rustprivacy.org/meta/mayflower.zip
Output is a short RDF "resource manifest" giving:
1) A Collection (list) of the HTML Profile URL, and other linked namespaces.
2) A Collection (list) of the Namespaces, Prefixes and (Said To Be) Languages
3) A Collection (list) of (qualified) terms used in this particular document.
What you will not see is any "gleaned" data - normally the point of GRDDL. The transform verifies that the meta data links in the <head> are properly in place according to the DCMI link syntax.
--Gannon
Received on Monday, 22 February 2010 20:38:32 UTC