Re: Content vs. Carrier

(at the risk of having this thread re-started ;-)

Sorry for reading these mails later...
I found it interesting. In fact I quite agree that Jeff's point can be valuable from a LD perspective. The notion of record will be useful for all applications that require provenance management, trust, and so on. A record is indeed an information resource, and if we represent it as such we can attach provenance data (who created the info, from which sources, when, who has rights, etc). We could thus represent records in RDF as a plain resource (as Jeff described in his UML) or even as some more sophisticated beasts such as named graphs (thus really capturing the context of a set of RDF assertions).

There is an interesting example at data.nytimes.gov. When NYT started their linked data site, they were aggregating all their data for a subject on a same resource. http://data.nytimes.com/N13941567618952269073 for example had both a label "Obama, Michelle", asserted to be sameAs resources of type person and had a copyright statement asserted on it. But pretty soon they opted for an approach that distinguishes the resource described (http://data.nytimes.com/N13941567618952269073) from an explicit information source describing it (http://data.nytimes.com/N13941567618952269073.rdf). The resource for the information object carries all the "management data" which does not define the concept per se. I think we can use a similar trick to allow for the notion of "record" to survive in a relevant way in a linked data environment.

The main message, though--and this is I think quite nicely conveyed by vocabularies like FRBR which put records aside--is that "records" in a LLD environment are no more essential to a core of application scenarios.
In the LLD approach a record (which is an information resource) without bibliographic data (which described non-information resources, even though in the "real world our books may be information resources but containing other data ;-) ) is meaningless, while bibliographic data could still be used independently of the record that initially contained it.

Cheers,

Antoine



> Karen,
>
> Sorry, I let this thread get stale.
>
> Note that I'm not "creating records" in my example. The records presumably already exist (think MARC here). What I'm suggesting is that we create a library ontology that contains "CatalogingRecord" as an owl:Class so we can make a sensible link between other ontologies (e.g. foaf, bibo, frbrFoo, vCard, etc.) and the library community's legacy concept of "record". See the attached UML. The same idea could apply to "AuthorityRecord", "HoldingsRecord", and the multitude of other "records" we have laying around.
>
> Call me backwards, but the concept of "record" isn't so completely alien to semantic reality that producers of Linked Data shouldn't even admit they exist.
>
> Jeff
>
> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Tuesday, July 13, 2010 5:57 PM
> To: Young,Jeff (OR)
> Cc: gordon@gordondunsire.com; public-lld
> Subject: Re: Content vs. Carrier (was: RE: [open-bibliography] MARC Codesfor Forms of Musical Composition)
>
> Quoting "Young,Jeff (OR)"<jyoung@oclc.org>:
>> FRBR is a technical model and at the risk of repeating old arguments
>>   I believe classes and individuals should to be linked to/from other
>>   models rather than conflating their identities.  To illustrate, I
>> don’t think that “CatalogingRecord” is a bad class to start creating
>>   Linked Data from. We don’t need to redesign cataloging databases
>> and  systems to produce Linked Data. Imagine a lightweight “library”
>>   ontology to help back up these examples involving 2 legitimate
>> CatalogingRecords (eng, ger) that describe a “single”
>> Work/Expression/Manifestation/Book:
>
> I'm unclear here why you are creating records. It seems that you are
> using the catalog document as your focus rather than the object of the
> catalog document. Can you explain better your use case for this kind
> of approach?
>
> Thanks,
> kc
>
>
>

Received on Sunday, 25 July 2010 12:32:32 UTC