See also DublinCoreEntryStrawman.
Echo Example Using the Dublin Core Metadata Element Set
The page contains some examples and discussion to how Echo could leverage DublinCore in its syntax.
NOTE: This proposal would fold the DublinCore semantics/labels into the core Echo namespace NOT create a seperate modulized namesapce. The use of dc: in the text below is meant to clarify what is coming from DublinCore and what is not.
DublinCore elements are already in common used within RSS feeds to supplement the core item elements of title, description and link. The DublinCore has corresponding elements for rss:title and rss:description, but a specific tag for (perma)link is not explictedly defined. The dc:source tag can reasonable be considered the links counterpart in the DublinCore. So with the DublinCore you can assemble what almost looks like an RSS feed item.
Looking at the Echo ConceptualModel, all of the required elements and many of the highly-recommended optional elements have corresponding elements to the DublinCore. Further clarifications and restraints are likely needed in the context of Echo's use For example, accordingly to the DublinCore documentation, dc:source is said to be "A Reference to a resource from which the present resource is derived. The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to identify the referenced resource by means of a string or number conforming to a formal identification system." In Echo the formal identification system would be a URL/permalink.
Another example is the dc:creator and dc:publisher elements. Currently these elements are just strings. Echo may further defined their format and content, optionally allowing for additional meta rich extensions such as FOAF to be substituted.
Echo would also benefit from defining maximum lengths and element optionality.
PROS
-
Leverages prior art
-
Leverages an international standard
-
Is not a radical departure from RSS today
CONS
-
Tag naming my not always be ideal
-
Additional clarification and restraints are needed
-
Elements may not be as meta rich as preferred
These examples illustrate what such an approach for Echo may look like. It assumes that the DublinCore namespace (http://purl.org/dc/elements/1.1/) is part of the default namespace. These elements are wrapped in a container tag of entry. Content is embedded using the root or container tag of the native format (assuming it can be expressed in well formed XML). Alternatively a content:encoded with CDATA encoding could be used to embed non-well formed textual content. Binary sources should not be embedded, but reference via a dc:related link.
Core ConceptualModel Entry
<entry xmlns="uri/of/echo/namespace/"> <source>http://www.example.org/archives/000000.html</source> <creator>Paul Harrison (http://www.example.org)</creator> <date>2003-06-25T10:42:00-04:00</date> <body xmlns="http://www.w3.org/1999/xhtml"> <p>A do try alone, my your you with get on friends. a my my, out from get. And i i your you're my do high. Think not from it you lend going a friends sang you. Be, lend away love little little. I because, to i ears, end, from do tune, alone a your help. Friends, i out, out get little, on if little of with my. Of of do a to key i get a my no sang is. Think <a href="http://www.foo.com/">help with what you sang</a> help a by i a how what get tune does because friends. Do do help tune, sad are when my from, feel own, sing a, you me the what get friends a.</p> </body> </entry>
Extended Entry
<entry xmlns="uri/of/echo/namespace/"> <title>With a Little Help From My Friends</title> <description>You a, you're get. Do my with. What with how think, sad on would how you try own a if by help and a i sang.</description> <source>http://www.example.org/archives/000000.html</source> <creator>Paul Harrison (http://www.example.org)</creator> <date>2003-06-25T10:42:00-04:00</date> <related>http://www.bar.net/000000.html</related> <related>http://www.baz.org/hello.html</related> <body xmlns="http://www.w3.org/1999/xhtml"> <subject>hello world</subject> <identifier>1056595208</identifier> <rights>Copyright 2003 Paul Harrison</rights> <p>A do try alone, my your you with get on friends. a my my, out from get. And i i your you're my do high. Think not from it you lend going a friends sang you. Be, lend away love little little. I because, to i ears, end, from do tune, alone a your help. Friends, i out, out get little, on if little of with my. Of of do a to key i get a my no sang is. Think <a href="http://www.foo.com/"> help with what you sang</a> help a by i a how what get tune does because friends. Do do help tune, sad are when my from, feel own, sing a, you me the what get friends a.</p> </body> </entry>
[KenMacLeod] In this example, it looks like <source> is being used where <identifier> should be used (see EntryIdentifier). 'http://www.example.org/archives/000000.html' appears to be the URI of the weblog Entry resource. I would expect <source> to be used to "reference to a resource from which the present resource is derived", where "present resource" is the weblog Entry. In other words, if the weblog entry was derived from some other resource, that URI would go into a <source> element.
I think this can be visualized more easily if you think of a weblog entry as '.../000000.html' and its metadata as '.../000000.echo'. A feed is a union of all the .echo files, and an entry is just the one. (Of course, in HTML one would put the metadata in <meta> elements, but I digress.)
Hmm, after a deeper look I'm more confused, more so than I'd consider just rewriting it. It appears that this example is effectively two resources. One resource can be seen in the <xhtml:body> element, and is the lyrics to a song, with rights, an identifer, and a subject (which should be a 'title'?) of "hello world". The second resource is the entry, everything outside the <xhtml:body>, with related entries, a creator, and a title of the entry. I can't tell if this confusion is from the example-nature of the data or something real. Again, maybe the visualization of .html/.echo (or HTML <meta> elements) will help see where I'm coming from.
[JamesSnell] I think this works just as well as anything else. I would like to see the above examples with namespaces included so I can get a better feel for how this comes together.
[KenMacLeod] Unless I'm mistaken, from the context of the outer element being <entry> and no qualifier on the inner elements, this is an example of deriving from DublinCore (derived as in "echo:date" IS-A "dc:date"), rather than using DublinCore terms directly. On that understanding, I've added just a default namespace to the <entry> element to clarify. See also DublinCoreEntryStrawman, EntryIdentifier, and TimestampVsCreationDateTime.
[DeveloperDude] +1 re-use of DublinCore.
-
The usage of DublinCore aggregated into the primary namespace is confusing and not helpful.
[TimothyAppnel] Ken is correct. What I propose is to simply fold the Dublin Core semantics and naming into echo.
-
[JamesSnell] Works for me
[RalphBrandi] If we're folding in Dublin Core, does that mean that <date.created> and <date.modified> would be valid? I believe just using <date> as in the example here is ambiguous, and Dublin Core allows for refinements to top-level elements.
-
[TimothyAppnel] Dublin Core does allow for more refinement see the Qualified Dublin Core (dcterms) module that was created for RSS 1.0
[KenMacLeod] I'm not sure of the extent we're talking about folding in or deriving from DublinCore. On the one hand we could be taking all the DublinCore terms and using them in the WellFormedEntry namespace, in which case the answer would be "yes". On the other hand, we could be creating specific terms in our namespace, and then using DublinCore definitions for them, in which case the answer would be "no or not necessarily, it would be a matter of choosing which terms we'll support". I'm comfortable with a "core" the size of DublinCore, but it appears that is an option that a lot of people are not comfortable with.
-
[TimothyAppnel] I was genrally thinking of taking all the DublinCore terms and using them in the WellFormedEntry namespace. While there seems to be a consensus towards a small simple core that minimizes the need to use namespaces in the basic usage patterns, it doesn't seem that there is consensus or agreement to what is or is not out of bounds. Hence my proposal to grab all the terms which I think covers all of the items being debated for use in the core. I'm not wedded to any specific terms. I am that we base this work on already existing prior art that is in use and has served us well.
[KevinBurton] Please do not fold the dublin core namespace. Is dc: and dcterms: please. Using a new namespace will destroy all the semantics that dublin core has achieved.
[TimothyAppnel] How? Namespaces don't bother me personally, but I think those who have asked to minimize the use of namespaces in common usage patterns have a point that needs to be explored. You need to ellaborate your point because I don't see wha tyou are talking about. (PS: Word of advice. I suggest you don't use the term "semantic web" or ontology or any thing of the sort if you want me to take you seriously.)
[KenMacLeod] Yes, minimization of or restricting to one core namespace has a strong consensus. Using DublinCore semantics to define WellFormedEntry elements alse seems to have very strong support, if not consensus. DublinCore has many precedents for using it as a reference in defining ones own terms, even if they are simply "is the same as". Those who need to equate the semantics at the exchange format level generally also have the tools to do so. See also RdfAndEcho.
[AsbjornUlsberg, RefactorOk] I just want to say it here as well, so it comes through: Dublin Core's use of the word "element" does not coherent with an XML element. A DC "element" is an entity, or a concept. The point is that DC standardizes entities; what they should be called, and what the meaning of them are. How these entities are implemented is up to us. We can use them as XML elements, as attributes, as attribute values; whatever. The main point is to use the same naming convention and put the same meaning in the entity as DC does.
CategoryArchitecture, CategoryMetadata, CategoryModel, CategorySyntax