RE: Records in (L)LD?

As you've described it, CBD would provide optimum generalized data
communication. 

Given a Linked Data URI like this:

http://example.org/work/1345 

I could imagine CBD Web document URIs like this:

http://example.org/work/12345/cbd (generic document)
http://example.org/work/12345/cbd.html
http://example.org/work/12345/cbd.ttl
http://example.org/work/12345/cbd.rdf
etc.

Including rdf:value/rdfs:labels would be the next logical generalizable
representation (especially if subclasses of rdfs:label were included). I
could imagine URIs that look like this:

http://example.org/work/12345/cbdplus (generic document)
http://example.org/work/12345/cbdplus.html
http://example.org/work/12345/cbdplus.ttl 
http://example.org/work/12345/cdbplus.rdf
etc.

Beyond that, the boundaries seem to depend on the domain model and use
cases. I could imagine a profiled boundary like this:
	
http://example.org/work/12345/profile1 (generic document)
http://example.org/work/12345/profile1.html 
http://example.org/work/12345/profile1.ttl
http://example.org/work/12345/profile1.rdf
etc.

An Atom Entry resource could make all of these representations
discoverable and discernable:

http://example.org/work/12345/entry.atom
http://example.org/work/12345/entry.rdf (AtomOwl) 

Crawling the cbdplus and profiled representations would be inefficient,
but for interactive use cases they would be handy. 

Given all the representation possibilities, it's fair to ask which one
should be delivered by default from an Accept: application/rdf+xml
request to the Linked Data URI. Because profiled representations are so
idiomatic, their discovery should probably be managed through Atom Entry
conventions.

Jeff

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Antoine Isaac
> Sent: Thursday, January 20, 2011 1:27 PM
> To: public-lld
> Subject: Records in (L)LD?
> 
> Hi Gordon,
> 
> Re. your questioning on the granularity of library metadata [1], and
> the notion of record, here's a link to one approach for data packaging
> in the LD realm: Concise Bounded Description (CBD, [2]).
> 
> The aim is to determine what data to send back for a given LD
> identifier, as "a general and broadly optimal unit of specific
> knowledge about that resource to be utilized by, and/or interchanged
> between, semantic web agents".
> I trust this somehow matches the concerns that guide the creation of
> records in library. I'm thinking for example when you decide how much
> of one concept's description you should include in the description of
> the book that has this concept as subject. Very often you would have
> both identifier and label for that concept in the book record, I
think.
> While only the identifier would be needed, in principle.
> 
> In theory, in the LD context, it would be sufficient to stop at the
> first de-referenceable identifier you bump into into when you navigate
> the graph of subject-predicate-object statements that "starts" at the
> resource of interest. Then, you can just fire a query for getting the
> description of this new identifier. This is the idea of CBD.
> 
> Yet CBD is only one of the algorithms that can be used to establish
the
> limit of data to send for an LD identifier. It's mentioned as one
> solution for SPARQL DESCRIBE query results [3], but that spec is not
> trying to enforce any option, truly:
> [
> This data [...] is determined by the SPARQL query processor. The
> DESCRIBE form takes each of the resources identified in a solution,
> together with any resources directly named by IRI, and assembles a
> single RDF graph by taking a "description" which can come from any
> information available including the target RDF Dataset.
> ]
> 
> One explanation for this is leaving the door open to optimizing data
> communication. For example, when you know that an data consuming
> application interested in one resource (e.g., a book) will almost
> always be interested in details for its related resources (e.g., its
> subject). In such cases, it helps if the packages of data shipped by
> the LD service have a slightly wider scope.
> 
> In fact the SPARQL doc even continues with a library example :-)
> [
> It may include information about other resources: for example, the RDF
> data for a book may also include details about the author.
> ]
> 
> I wonder whether there could be something in the existing library data
> exchange practices, which could be adapted to the LD world. I'd be
> interested to hear opinions on this!
> 
> Best,
> 
> Antoine
> 
> [1]
>
http://www.w3.org/2005/Incubator/lld/wiki/Granularity_of_library_metada
> ta
> [2] http://www.w3.org/Submission/CBD/
> [3]http://www.w3.org/TR/rdf-sparql-query/#describe
>

Received on Thursday, 20 January 2011 19:27:35 UTC