Kendall Clark wrote:
>
> >>>>> "Paul" == Paul Jones <[EMAIL PROTECTED]> writes:
>
> Paul> On Mon, 25 Oct 1999, Deb Richardson wrote:
> >> Hi Paul...here are my quick notes from an initial read-through:
> >>
> >> --- 9. Resource Type Label: TYPE Obligation: Optional Maximum
> >> Occurrence: Repeatable The category of the resource. To
> >> promote consistency, TYPE should be selected from the following
> >> list: HOWTO mini-HOWTO user's guide administrator's guide
> >> programmer's guide installation guide ---
> >>
> >> Is the list of document types extensible? I can think of a
> >> couple of others I would like to add for the OSWG, for example
> >> ("article", "research paper").
> Paul> yes it is extensible and it would be simple and good to add
> Paul> the type you mention
>
> Of course, how and when and why and who does this is still all open; I
> suspect that this is part of what Jane wants to tell us on her return
> from hanging out with the Dublin Core bigwigs. (I'm so jealous! :> )
>
> I'm in favor (but I fear I'm the only one) of defining formal
> vocabularies using SGML/XML entity sets, for which we also can
> generate metadata so they can be discovered as Just Another Kind of
> Resource.
>
> >> I'm also a little confused about the fact that the type can be
> >> repeatable. Does this mean you can classify a single document
> >> in more than one type catagory? (I've possibly missed
> >> something :->)
> Paul> yes something could conceivably be considered a research
> Paul> paper might become a chapter or a mini-How-To might graduate
> Paul> to a How-To
>
> Yes, it could be used in at least two ways: (1) track the history of a
> resource, and (2) some resources really do just belong in multiple
> categories.
>
> However, I do think (but, again, I may be the only one) that we
> should, perhaps before releasing 1.0, carefully consider whether each
> and every LDP Core element is both repeatable and optional. I can
> imagine situations where this will just cause problems, at least in
> the absence of some other meta-metadata that can help resolve
> ambiguities.
>
> Example: a document has three titles. Which one should my Python robot
> use? Well, if we carefully track dates and change sets (which our DTD
> supports) then I can say, "well, I have 3 titles here, so I'll just
> take the latest one; or, alternately, since all 3 have a modification
> date, I can use all 3 but sort them from latest to original.) Note: if
> title isn't repeatable, this problem doesn't really come up.
>
> >> --- 14. Relation Label: RELATION Obligation: Optional Maximum
> >> Occurrence: Repeatable A URL that points to the IDENTIFIER
> >> element of another resource. Each instance of RELATION links
> >> the resource to other resources of similar domain or style.
> >> ---
> >>
> >> I'm not quite sure I understand the purpose of "relation".
> >> Could you expand on that a bit here?
> Paul> as i understand it (kendall and miles feel free to jump in
> Paul> and set me straight). relation is for say chapters and parts
> Paul> of collections or say a conference paper etc.
>
> Yeah, this is basically right, Paul; but it's more flexible as well;
> you can list mirrors in a relation element for example.
>
> I do think that for the full-on 1.0 release of LDP Core, we should
> think seriously about adding some kind of type to RELATION, so that
> you could do stuff like:
>
> <relation type="isMirrorOf|isAKindOf|isAPartOf|..." ../>
>
> >> Finally, from the last section (15), I assume that the list of
> >> licenses allowed in the RIGHTS.type catagory is
> >> modifiable/extensible. (?) I doubt the list of
> >> open-source/open-content licenses is anywhere near static at
> >> this point :>
> Paul> exactly
>
> >> I like the xmlifier. Once the information is xmlified,
> >> however, what's to be done with it? I'm not quite sure I
> >> understand what the "big picture" of the project is. Could you
> >> walk me though it a bit?
>
> Paul> well, we know that a variety of XML databases will be
> Paul> thrashing it out soon. we have an XML search engine that we
> Paul> will be trying soon, i hope, from etymon and invisible
> Paul> worlds, but the collection of metadata, like the LSMs, could
> Paul> and should be distributed so that others could also provide
> Paul> solutions as they see fit. ours will likely look like
> Paul> linsearch in at least one incarnation. but you can't search
> Paul> without well-marked up, well-defined content so this is an
> Paul> effort to create that content in as simple a way as possible
> Paul> while still including enough information to be useful. you
> Paul> may think of these entries of card catalogue records with
> Paul> links to the data objects/documents that can be filed,
> Paul> selected and sorted by anyone.
>
> Right. Basically you can do with this whatever you can do with RDF
> stuff generally; so I suspect, in addition to what Paul's mentioned,
> command-line tools for searching LDP (and other) collections in nicely
> constrained ways (I predicted this in my LDP DigLib essay; a
> command-line tool 'ldpfind' like Veillard's excellent rpmfind); this
> will also make it possible to build meta-collections around LDP
> collections in intelligent ways.
>
> Intelligent metadata opens up a lot of avenues of information reuse,
> repurposing, etc.
>
> As usual, just my 2 cents; I don't do this for a living! (I just want
> to! :> )
>
> Best,
> <Kendall/>
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
