Mike Linksvayer wrote: > You replied offlist, in case that was not intentional feel free to > follow up on or off...
It was a mistake... > On Mon, 2007-03-26 at 10:46 -0500, Terry Hancock wrote: > >>Mike Linksvayer wrote: >> >>>XMP is just a constrained RDF serialization. DC can be represented as >>>triples as well, might want to think internally in triples and serialize >>>them as appropriate for the XMP/native/whatever format. >> >>This may be an example of me being "constrained by my tools" in my >>thinking, but what do "triples" really buy us in this problem domain? >>I'm working in Python, where a simple map (dictionary) is a natural >>aggregate datatype (I guess you could call it a "double" :-) ). > > > If you have use cases like derivation you're be definition talking about > multiple works, so you need a way to identify what work you're talking > about. > > I suppose you implicitly get this with a dictionary per work. > > >>In practice, this usually means the "operator" part of triples is >>implied (I have named fields which map to values -- the mapping is >>assumed to have the same meaning for the whole dictionary). >> >>In the case of DC, the implied operator is basically "is" or "contains", >>as in "'Creator' contains 'Jane Doe' and 'Joe User'" (which means they >>are both authors of the work). > > 'Creator' is the operator and means something like "has this creator". > The DC-in-RDF guidelines should make this clear, if nothing else does. > Though re-reading the above I suppose you could think of each > term/predicate having an implied is/contains/some other relationship > implied. I see -- so in my case, it's actually the "subject" that is implied, not the "predicate". >>Supposing I implement an internal representation of RDF triples... what >>do I win? :-) >> >>Or put another way, how many operators are actually sensible in this >>context? > > Operators, if I understand your use above, are never explicit in RDF or > DC. The "triple" is subject (e.g., a work), predicate (e.g., > creator/license/source/...), object (e.g., Bob/BY-SA/sourceURI/...) > > >>Not that I'm criticizing the idea -- I just want to understand my choices. > > Maybe not much, I dictionary per thing being described essentially gets > you the same thing. Yeah, I think so. Certainly I intend for the DC object to apply to exactly one work. Realizing the semantics of the RDF/DC concept helps me, though. I must say I am bothered by the use of nouns to represent "predicates", though -- seems a little linguistically broken. ;-) In general, ISTM, that you want to have reducing operations on such information -- when two people collaborate to make a new work (or one person derives a new work from an original), you want to have just one licensing and attribution statement for the resulting work. It might be nice detail to know who did what exactly, but you also want the condensed version that says "this is who you have to credit when you use this work". In fact, what you (or I) really want is to have the library just flat out tell you the exact wording of the notice you need to use. At first it seemed to me that sub-file resources would primarily be only of interest to document formats like PDF, but I considered that even with seemingly single-work formats like JPG, it's possible to combine multiple works into one document (as in the case of an array of pictures combined into a single image file). In this case, the ability to refer specifically to a particular part of the rendered data is meaningful. So it'll need to be a general capability. So far, though, I'm skirting that issue -- I'm hoping to leave enough hooks in place so that it can be added on later. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ cc-devel mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/cc-devel
