> From [log in to unmask] Wed May 29 16:08 MET 2002
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i, Unixmail for Windows 0.6
> Date: Wed, 29 May 2002 16:08:32 +0200
> From: Thomas Baker <[log in to unmask]>
> Subject: Re: Representing DCMI semantics as RDF schemas versus Web pages
> To: [log in to unmask]
>
> On Wed, May 29, 2002 at 12:54:55PM +0200, Roland Schwaenzl wrote:
> > well...one better should look for
> >
> > http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/Schema/A/terms
>
> I think you mean
> http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/Schema/A/dcterms?
>
Yupp! That's called the slim version. Plain vanilla RDF.
> I see that this version does not include the RangeOf
> construct, making it even closer to my text representation.
> I also noticed a neat assertion in there I had missed before
> (rdfs:label subPropertyOf dc:title).
>
> > What is in there should suffice as support of the dc-web-site
> > for RDF applications. That is for instance what an RDF Schema
> > intended for.
>
> Looking at the declaration of "dcterms:alternative" (where "---"/"+++"
> indicates whether something is found in my text representation):
>
> +++| <rdf:Property rdf:about="http://purl.org/dc/terms/alternative">
> +++| <rdfs:label xml:lang="en">Alternative</rdfs:label>
> +++| <rdfs:comment xml:lang="en">Any form of the title used as a substitute or
> +++| alternative to the formal title of the resource.</rdfs:comment>
> +++| <dc:description xml:lang="en">This qualifier can include Title
> +++| abbreviations as well as translations.</dc:description>
> +++| <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/title"/>
> ---| <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/terms/"/>
> +++| <dcterms:issued>2000-07-11</dcterms:issued>
> | </rdf:Property>
> (Note that I have expanded the namespace references.)
>
> I find a few differences with respect to my text representation
> (where "---"/"+++" indicates whether something is captured
> by the RDF schema above):
>
> ---| VMS-ID: alternative-002
> +++| Name: alternative
> +++| URI: http://purl.org/dc/terms/alternative
> +++| Label: Alternative
> +++| Definition: Any form of the title used as a substitute or alternative
> +++| to the formal title of the resource.
> +++| Comment: This qualifier can include Title abbreviations as well
> +++| as translations.
> ---| Term Type: http://dublincore.org/usage/documents/mission/#element-refinement
> +++| subPropertyOf: http://purl.org/dc/elements/1.1/title
> ---| Decision: http://dublincore.org/usage/decisions/#2002.01
> ---| Date modified: 2002-06-15
> +++| Date added: 2000-07-11
> ---| Supersedes: http://dublincore.org/usage/terms/dc/#alternative-001
> ---| Status: http://dublincore.org/usage/documents/process/#recommended
>
> The RDFS representation lacks information on Status, Term Type,
> and Versioning (VMS-ID, Decision, Date modified, Supersedes). If the
> schema is sufficient as support for RDF applications, this means that
> an RDF application would not need these things?
It has dcq:modified, where modifications are known to the public.
As the integrity of applications requires existing terms never change semantics,
modifications are limited to changes of non-vital properties of the resources.
>
> Regardless of the answer, I find myself puzzled by the
> implications of one assertion in the RDF schema:
>
> dcterms:alternative isDefinedBy http://purl.org/dc/terms/
>
> According to http://www.w3.org/2000/01/rdf-schema,
> "isDefinedBy" means "Indicates a resource containing and
> defining the subject resource".
http://www.w3.org/TR/2000/01/CR-rdf-schema-20000327/#s2.3.5
should clarify your concern.
[It mentions dc explicitly].
> I am confused because
> I think of "alternative" as being uniquely _identified_
> by the string http://purl.org/dc/terms/alternative but
> actually _defined_ and documented in the Web resource
> http://dublincore.org/usage/terms/dc/ (to be precise, at
> http://dublincore.org/usage/terms/dc/#alternative-002).
DC has in a formal fashion defined, what it's namespace URI's
are. Before the DCMI namespace rec was made one could have
argued as you do. It's an advantage for DC to have this standard.
>
> > [This doesn't say, that all RDF applications will just use
> > such a slim version. ]
>
> I am assuming that one could declare the "missing" information
> from my text description as RDF assertions as well...
That's not the point.
>
> > Your question about automatic generation:
> >
> > That may depend on the metadata/structure of the documents
> > /usage/terms/dc/ cites.
> >
> > In case the snippets of information one wants to see in a
> > Schema ready for machine consumption, which uses standardized
> > vocabulary and formal syntax to express (semantic) relations
> > and rules to machines can safely be picked up from documents
> > intended for human consumption - of course you can write a
> > program - but you're left to define (!), what will be mapped
> > to what....i.e. and additional set of rules.
>
> In that sense, a Perl script is (inherently) a set of
> such rules? Making the text document safe for precisely
> such conversion is what I would like to be able to do.
Come on....we then still would have to decide, how the
conversion should be done.
How the vocabulary management system is supposed to
work internally is not my current business.
>
> > For that it's a bit confusing, that usage/terms/dc/ mixes
> > seemingly (?) existing metadata vocabulary with it's own terms
> > - technically speaking it's not clear whether an additional
> > namespace is asked for to represent the terms used in an
> > RDF Schema.
>
> Yes indeed. That's why I am making a point of inviting
> comments on that attribute set now, before the concrete sets.
Huch! You actually want a formal model for the text file?
Why then to worry about the text file at all? Of course
you could model the text file and create the text file from
the model. In my view this is again a question on a vocab. management
system. To maintain the text file by hand in the long run
will not work (i think). The text file is just another view the
system is supposed to provide.
> And I was always assuming that this vocabulary would itself
> need to be declared (eg, "Decision").
By what means?
>
> > In the Scheme/A/terms approach things are expressed using DC
> > and RDFS vocabulary only.
>
> I'd be very happy to change the attributes to make the text
> description more "plain vanilla" DC/RDFS. Suggestions most
> welcome.
>
> > One example: Speaking RDF usage/terms/dc seems to introduce
> > a Class called "Decision" and goes ahead in typing certain
> > documents as members of the Class. The pointer to such a
> > document is an rdfs:seeAlso - In case one thinks it's important
> > for the functionality of arbitrary RDF applications based
> > on DC vocabulary to know about certain documents represent
> > decisions - one will need a namespace outside the range of the
> > dcmi namespace recommendation to host a Class named "Decision".
>
> I'm not sure it is important as long as the RDF schema points
> back to the "canonical" representation (assuming for the sake
> of argument that it is http://dublincore.org/usage/terms/dc/).
?? Canonical? How you create xml-schema from it?
> For the sake of making the RDF schema more plain-vanilla
> DC/RDFS, I'd be happy to see the link to a decision expressed
> as an rdfs:seeAlso. I'm inclined to call it "Decision" in
> the text document because the whole system is designed to
> associate each change of version with exactly one uniquely
> identified Decision.
>
??
> > Similarly it is with the supersede property: Is it used -
> > as one would expect - as a subProperty of dcterms:replaces
> > or is it used to indicate versioning (of what)?
>
> "Replaces" works just as well for me, especially since it
> is defined as "The described resource supplants, displaces,
> or supersedes the referenced resource". I do not recall
> when or how I started using "Supersedes"... At any rate,
> the use here is to indicate successive versions of a DCMI
> Term Declarations -- in RDF terms, of the Property Declaration.
As i said before: The definition of a property never is supposed
to change.
rs
>
> Many thanks,
> Tom
>
> --
> Dr. Thomas Baker [log in to unmask]
> Institutszentrum Schloss Birlinghoven mobile +49-171-408-5784
> Fraunhofer-Gesellschaft work +49-30-8109-9027
> 53754 Sankt Augustin, Germany fax +49-2241-14-2619
>
|