Re: reconciliation of disparate models - Corey

Corey:

    Another quick follow-up on the blank-nodes question. I'm kind of
    surprised to see the general aversion.

    I've come to generally think of the blank-node as a reasonable
    solution to meet strict constraints in cases where they may or may not
    be relevant to your internal needs. I may not have made it clear, but
    I was thinking of the blank nodes cases as more of an export format if
    your storing your initial data as Bibo, eg.

    In any event, I've also thought this was necessary in the context of
    exposing metadata using dcterms, which is where I first hit on the
    idea. It's not a domain problem there, but rather the range problem...
    Point being, the proscription from using literals means that I would
    need objects that correspond to my publishers and coverage places,
    etc. But my systems aren't designed that way, so I still use strings
    in that data.

    My thinking had always been to use dummy nodes in exactly this way:

    My data is likely to look like:
    <http://example.org/some-image> a rdf:Resource ;
                dc:publisher "Harper Collins" ;
                dc:type "Image"

    But I could share it as:
    <http://example.org/some-image> a rdf:Resource ;
                dcterms:publisher _:blank1 ;
                dcterms:type <http://purl.org/dc/dcmitype/Image>

    _:blank1 a foaf:Organiziation
               foaf:name "Harper Collins";

    Now, I'm also in favor of the unconstrained versions, and in fact
    fully support "free-range-metadata" as I called it when talking to Tom
    recently. But, even setting aside my poor example, there are many
    elements in the dcterms namespace that don't have free-range brethren
    and would basically require this approach. And again, to my mind the
    two examples above are really the same metadata.

    Is there a reason that would be okay here but not in my mangled
    FRBR-RDA examples?

    Okay - that's all for now. More on the FRBRer FABio and RDA after some
    unwired time.


-- 
Tom Baker <tbaker@tbaker.de>

Received on Sunday, 13 March 2011 23:42:46 UTC