Adam,
Like I said, I'm not an XML expert at all. So I'll pass your question to
the expert who helped us out on this.
As far as I could understand when we created our xsd for permits [1],
the way they wanted to specify spatial did not match the requirements of
the DCMI Description Set Model [2]. The specification of the possible
values of a property is rather complex and abstract, but boils down to:
'a value can be a literal represented by a string or a non-literal
represented by a string from a specified vocabulary or by a URI.'. So
that would not allow for the complex values like you propose. Our xsd
for permits therefor created their own element outside the OWMS-core.
It's the object element at line 115 in [1] which describes the object of
the permit. It can be a piece of land, an adress, a building, a street.
A speed course Dutch:
huis = house
huisnummertoevoeging = any addition after a house number like the B in
'16 B'
woonplaats = place of residence/settlement
gemeente = municipality
perceel = piece of land according to the land registry
[1] http://standaarden.overheid.nl/vergunningen/4.0/xsd/zaak/vgzaak.xsd
[2] http://dublincore.org/documents/abstract-model/index.shtml#sect-2
groet,
Hans
> -----Oorspronkelijk bericht-----
> Van: General DCMI discussion list
> [mailto:[log in to unmask]] Namens Retter, Adam
> Verzonden: maandag 17 oktober 2011 15:08
> Aan: [log in to unmask]
> Onderwerp: Re: Guidance on DC Schema extensibility
>
> Hans,
>
> Firstly thanks for the reply :-)
>
> I did consider creating a Dublin Core Application profile,
> however this seemed like a huge amount of work and I had to
> take the pragmatic route that I probably only have several
> days to achieve results that can be used for implementation.
> Our metadata requirements at the moment are entirely
> internal, as such I have created a small set of guide
> documents which describe the DCMI terms that should be
> applied to what and when, I imagine that this could later be
> used as the basis for a full Dublin Core Application Profile.
>
> I am REALLY looking for guidance on how this should be
> expressed in XML and XML Schema as per my examples, I did
> take a look at your XML expressions, but these only use
> simple string values and describe how these should be
> expressed. Rather I am looking to use complex XML snippets as
> the values of my Dublin Core terms. I wonder if you don't do
> this, because it is not an appropriate thing to do? Do you
> have contact with those that defined your XML Schemas for
> this, perhaps they could comment?
>
>
> Cheers Adam.
>
> -----Original Message-----
> From: Hans Overbeek [mailto:[log in to unmask]]
> Sent: 17 October 2011 13:10
> To: Retter, Adam; [log in to unmask]; DCMI Government Community
> Subject: RE: Guidance on DC Schema extensibility
>
> Hi Adam,
>
> For ther Dutch government we developed a Dublin Core
> Application profile which we use again as an intermediate
> standard between Dublin Core specifications and the specific
> application standards. The standard is called OWMS
> (Overheid.nl Web Metadata Standard. 'Overheid' means
> 'Government'). It is published in Dutch at [1] but wit Google
> translate [2] you should get a picture. The only
> documentation in english is a technical review of OWMS 3.5 in
> 2008 [8].
>
> Important in our case is of course the translation of the
> DC-terms into Dutch, but we also narrow down the semantics of
> the DC terms a little bit to the government domain and our
> needs. For instance, we define our own core-properties: A set
> of 9 properties that are mandatory if applicable. This
> encourages implementing parties to use the standard.
> We also defined a namespace 'overheid' ('government') to hold
> terms that can be used in many applications. In this
> namespace we defined a new property 'overheid:authority' [3]
> with semantics that we need in a government context and which
> are not covered by the Dublin Core terms.
> The 'overheid:authority' is the governmental organisation
> that is to be held legally responsible for the content
> (meaning) of the information object. This is often, but not
> necessarily, the same organisation as the creator.
>
> The namespace also contains some lists of values that can be
> used to specify the properties [4]. So for instance, we
> publish lists with government organisations and a list with
> information types.
>
>
> We than created a technical framework that allowed others to
> define their own application profile on top of our
> specifications. The framework enforces that the nine core
> properties are used, it supports re-use of our lists of
> values and other Dublin Core properties, and it allowes to
> extend the scheme with application specific properties and
> lists of value.
>
> The framework consists of a set of XSD's [5] and supported by
> Schematron rules to perform the look-up of the lists of values.
>
> We tried out two approaches: OWMS full and OWMS plugin.
> The OWMS full approach provides for a template XSD that can
> be extended for your own needs.
> The OWMS plugin XSD's can be plugged into an existing XSD. It
> is more flexible to apply, but it is less strict with respect
> to the constraints we can enforce.
>
>
> RE: dcterms:spatial [6] we only support postal code/house
> number and organisation, where the latter has to be explained
> as the mandated territory of the organisation mentioned. This
> was not enough for some application profiles, so they worked
> their way around it. se for example the application profile
> (or content model as we call it) for permits.
> [7] My knowledge of XML is too poor to give detailed feedback
> on your examples, sorry.
>
> In practice we see that simplicity usually wins from
> completeness. So people prefer pragmatic sollutions and
> accept it does 'only' 80-90 % of the job. We therefor aim at
> future use of URI's from the National Geo Registers that are
> under development right now, rather than developing
> structures to specify literal values right now.
>
>
> These are interesting challenges we are facing. And I'm sure
> we are looking at the comparable problems in many countries.
> Therefor I also post my response to th DC-Government list
> where we discuss these kind of problems and solutions in a
> government context.
>
> All,
> Please share your views!
>
>
> [1] http://standaarden.overheid.nl/owms/
> [2]
> http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=ht
> tp%3A%2F%2
> Fstandaarden.overheid.nl%2Fowms%2F
>
> [3] nl
> http://standaarden.overheid.nl/owms/4.0/doc/eigenschappen/over
> heid.autho
> rity.html
> [3] en
> http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=ht
> tp%3A%2F%2
> Fstandaarden.overheid.nl%2Fowms%2F4.0%2Fdoc%2Feigenschappen%2F
> overheid.a
> uthority.html
>
> [4] nl http://standaarden.overheid.nl/owms/4.0/doc/waardelijsten/
> [4] en
> http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=ht
> tp%3A%2F%2
> Fstandaarden.overheid.nl%2Fowms%2F4.0%2Fdoc%2Fwaardelijsten%2F
>
> [5] nl http://standaarden.overheid.nl/owms/4.0/schemas4.0.html
> [5] en
> http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=ht
> tp%3A%2F%2
> Fstandaarden.overheid.nl%2Fowms%2F4.0%2Fschemas4.0.html
>
> [6] nl
> http://standaarden.overheid.nl/owms/4.0/doc/eigenschappen/dcte
> rms.spatia
> l.html
> [6] en
> http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=ht
> tp%3A%2F%2
> Fstandaarden.overheid.nl%2Fowms%2F4.0%2Fdoc%2Feigenschappen%2F
> dcterms.sp
> atial.html
>
>
> [7] nl http://standaarden.overheid.nl/vergunningen/
> [7] en
> http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=ht
> tp%3A%2F%2
> Fstandaarden.overheid.nl%2Fvergunningen%2F
>
> [8] en
> http://www.e-overheidvoorburgers.nl/binaries/overheidheeftantw
> oord/pdf/m
> etadata/owms_final_report_20081212.pdf
>
> With kind regards,
> Hans Overbeek
> Consultant Content Standards
>
> e-Overheid voor Burgers
>
>
> ICTU
> Wilhelmina van Pruisenweg 104, 2595 AN Den Haag Postbus
> 84011, 2508 AA Den Haag Tel. +31-6-1830 7858, Secretariaat
> 070 - 888 78 50
> E-mail: [log in to unmask]
> Internet: www.e-overheidvoorburgers.nl
> http://www.overheid.nl
> http://mijn.overheid.nl
> http://standaarden.overheid.nl
> http://data.overheid.nl
>
>
>
> > -----Oorspronkelijk bericht-----
> > Van: General DCMI discussion list
> > [mailto:[log in to unmask]] Namens Retter, Adam
> > Verzonden: maandag 17 oktober 2011 11:05
> > Aan: [log in to unmask]
> > Onderwerp: Guidance on DC Schema extensibility
> >
> > Hi there,
> >
> > I am looking for some advice on best practice of refining/extending
> > Dublin Core, specifically we are constrained by XML Schema
> and so RDF
> > options are not possible. My position here is to create an
> XML Schema
> > that holds metadata about resources and processes. I feel
> that it is
> > important to reuse existing standards where possible rather than
> > inventing the wheel again, as such I am looking to the DCMI
> Metadata
> > Terms.
> >
> > Some existing DCMI Metadata Terms are a natural fit for this, e.g.
> > title, language, publisher. However, others lack the precision
> > semantics that we need, I have identified two possible ways
> in which
> > we could incorporate this precision with Dublin Core, but
> am unsure of
> > the best approach and would appreciate some advice from the Dublin
> > Core perspective.
> >
> > Consider for example dcterms:spatial, a simple literal value is not
> > enough for us, we need a complex addressing mechanism -
> >
> > Approach 1, make use of xsi:type by extending dc:SimpleLiteral -
> >
> > Example XML -
> > <dcterms:spatial xsi:type="m:address">
> > <m:address-line>102</m:address-line>
> > <m:address-line>Some Road</m:address-line>
> > <m:settlement xsi:type="dcterms:TGN">York</m:settlement>
> > <m:county>Yorkshire</m:county>
> > <m:country>GB</m:country>
> > </dcterms:spatial>
> >
> > Example XML Schema snippet for 'm' -
> > <xs:complexType name="address">
> > <xs:annotation>
> > <xs:documentation xml:lang="eng">Restriction of the spatial
> > coverage for use in Dublin Core's dc:spatial e.g. The geographical
> > area/address represented</xs:documentation>
> > </xs:annotation>
> > <xs:complexContent mixed="true">
> > <xs:extension base="dc:SimpleLiteral">
> > <xs:sequence>
> > <xs:choice maxOccurs="unbounded">
> > <xs:element name="address-line"
> > type="xs:string" maxOccurs="unbounded"/>
> > <xs:element name="settlement" type="xs:string">
> > <xs:annotation>
> > <xs:documentation>Should consider
> > restricting values to a controlled vocabularly such as Getty TGN
> > through xsi:type="dcterms:TGN"</xs:documentation>
> > <xs:appinfo>
> >
> > <dcterms:hasFormat>http://purl.org/dc/terms/#ves-TGN</dcterms:
> > hasFormat>
> > </xs:appinfo>
> > </xs:annotation>
> > </xs:element>
> > <xs:element name="county" type="xs:string">
> > <xs:annotation>
> > <xs:documentation>Should consider
> > restricting values to a controlled vocabularly such as Getty TGN
> > through xsi:type="dcterms:TGN"</xs:documentation>
> > <xs:appinfo>
> >
> > <dcterms:hasFormat>http://purl.org/dc/terms/#ves-TGN</dcterms:
> > hasFormat>
> > </xs:appinfo>
> > </xs:annotation>
> > </xs:element>
> > <xs:element name="country"
> > type="stl:ISO3166CountyCode"/>
> > <xs:element name="postal-code"
> type="xs:string"/>
> > </xs:choice>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> >
> > Approach 2, make use of substitution groups -
> >
> > Example XML -
> > <m:address>
> > <m:address-line>102</m:address-line>
> > <m:address-line>Some Road</m:address-line>
> > <m:settlement>York</m:settlement>
> > <m:county>Yorkshire</m:county>
> > <m:country>GB</m:country>
> > </m:address>
> >
> > Example XML Schema for 'm' -
> > <xs:element name="address" type="addressType"
> > substitutionGroup="dcterms:spatial"/>
> > <xs:complexType name="addressType">
> > <xs:sequence>
> > <xs:choice maxOccurs="unbounded">
> > <xs:element name="address-line" type="xs:string"
> > maxOccurs="unbounded"/>
> > <xs:element name="settlement" type="xs:string">
> > <xs:annotation>
> > <xs:documentation>Should consider restricting
> > values to a controlled vocabularly such as Getty TGN through
> > xsi:type="dcterms:TGN"</xs:documentation>
> > <xs:appinfo>
> >
> > <dcterms:hasFormat>http://purl.org/dc/terms/#ves-TGN</dcterms:
> > hasFormat>
> > </xs:appinfo>
> > </xs:annotation>
> > </xs:element>
> > <xs:element name="county" type="xs:string">
> > <xs:annotation>
> > <xs:documentation>Should consider restricting
> > values to a controlled vocabularly such as Getty TGN through
> > xsi:type="dcterms:TGN"</xs:documentation>
> > <xs:appinfo>
> >
> > <dcterms:hasFormat>http://purl.org/dc/terms/#ves-TGN</dcterms:
> > hasFormat>
> > </xs:appinfo>
> > </xs:annotation>
> > </xs:element>
> > <xs:element name="country"
> type="stl:ISO3166CountyCode"/>
> > <xs:element name="postal-code" type="xs:string"/>
> > </xs:choice>
> > </xs:sequence>
> > </xs:complexType>
> >
> >
> > My feeling is that the first approach is the preferred mechanism as
> > when you look at or process the metadata it is absolutely explicit
> > that this is a dcterms:spatial, and if you received this
> document as a
> > 3rd party then as a minimum you were just able to extract the text
> > nodes, you would have a strict dcterms compliant spatial property.
> > One downside to this is that we have to sprinkle xsi:type attribute
> > annotations into our XML instances. However there is also
> an advantage
> > to this, which is that in future if we have values that we have
> > non-anticipated we can simply create new complexTypes for
> refinement,
> > or even default to the lowest common denominator i.e.
> dc:SimpleLiteral
> > which is just an xs:string.
> >
> > I would appreciate thoughts on this from the Dublin Core
> perspective,
> > how have others done this in the past, what is the recommended best
> > practice?
> >
> >
> > Thanks Adam
> >
> > Please don't print this e-mail unless you really need to.
> >
> > --------------------------------------------------------------
> > -------------------
> >
> > National Archives Disclaimer
> >
> > This email message (and attachments) may contain
> information that is
> > confidential to The National Archives. If you are not the intended
> > recipient you cannot use, distribute or copy the message or
> > attachments. In such a case, please notify the sender by
> return email
> > immediately and erase all copies of the message and attachments.
> > Opinions, conclusions and other information in this message and
> > attachments that do not relate to the official business of The
> > National Archives are neither given nor endorsed by it.
> >
> > --------------------------------------------------------------
> > ----------------------
> >
> >
>
> Please don't print this e-mail unless you really need to.
>
> --------------------------------------------------------------
> -------------------
>
> National Archives Disclaimer
>
> This email message (and attachments) may contain information
> that is confidential to The National Archives. If you are not
> the intended recipient you cannot use, distribute or copy the
> message or attachments. In such a case, please notify the
> sender by return email immediately and erase all copies of
> the message and attachments. Opinions, conclusions and other
> information in this message and attachments that do not
> relate to the official business of The National Archives are
> neither given nor endorsed by it.
>
> --------------------------------------------------------------
> ----------------------
>
>
|
