- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Wed, 1 Sep 2010 11:07:47 -0400
- To: "Thomas Baker" <tbaker@tbaker.de>, "Karen Coyle" <kcoyle@kcoyle.net>
- Cc: <public-lld@w3.org>
I have the feeling that "application profiles" aren't necessary for OWL vocabularies because they are relatively self-explanatory. DC vocabularies don't use OWL so they have to be explained with "application profiles". IMO, Linked Data is easier to understand if it the resources are based on OWL. Comments? dc: http://purl.org/dc/elements/1.1/ dcterm: http://purl.org/dc/terms/ dcam: http://purl.org/dc/dcam/ dctype: http://purl.org/dc/dcmitype/ others? Jeff > -----Original Message----- > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On > Behalf Of Thomas Baker > Sent: Wednesday, September 01, 2010 10:30 AM > To: Karen Coyle > Cc: public-lld@w3.org > Subject: Re: Library data diagram > > Thank you, Emmanuelle, for drawing up the comparative > diagrams [1] and thank you, Karen, for getting the ball > rolling on discussion. > > A comment specifically on Singapore Framework [2]... > > On Tue, Aug 31, 2010 at 08:38:36PM -0700, Karen Coyle wrote: > > The Singapore Framework places guidance rules outside of the flow of > > vocabulary and DCAP development. This makes me think that in SF the > > guidance rules are developed and applied after the other steps toward > > an application profile have taken place. > > As I see it, the SF diagram is intended to show how the > components of an "application profile" relate to each other > and to underlying foundational standards (RDF). > > The diagram does also suggest a workflow, and I too like to > present it this way -- starting with Functional Requirements, > through defining a Domain Model, specifying a Description Set > Profile and, finally, creator a Data Format, with the designer > "dipping down" one level to create new or cite existing domain > models and vocabularies. And as a rough approximation, this > seems like a reasonable way to proceed as long as it is not > applied too mechanically. In the end, though, SF is meant > to depict less a specific sequence of tasks than a picture of > how things relate. > > > This is accurate in terms of > > Dublin Core metadata, which was developed initially without actual > > guidance rules. > > > > In Emmanuelle's diagram of library metadata, the guidance rules > appear > > to precede the vocabulary. This is accurate in terms of library > > metadata, in which the vocabularies arise from the guidance rules. > > > > These two models, DC and libraries, seem to me to be the extremes of > > the development continuum. In libraries the guidance rules are the > > most important aspect of the metadata creation activity, and in > Dublin > > Core they can almost be considered unnecessary. > > If for libraries, guidance rules are the point of departure for > metadata design, then "support for guidance rules" would quite > simply need to be defined as a key functional requirement. > > If this is done, then the metadata creation workflow in > libraries can be seen as fitting both the Singapore Framework > view and its implied workflow (which starts with Functional > Requirements) -- only that, in this case, the functional > requirements may be unusually heavy on existing guidance > rules... > > Tom > > [1] http://www.w3.org/2005/Incubator/lld/wiki/File:LayeredModelV3.pdf > [2] http://dublincore.org/documents/singapore-framework/ > > -- > Tom Baker <tbaker@tbaker.de> >
Received on Wednesday, 1 September 2010 15:08:26 UTC