> From: DCMI Architecture Forum [mailto:[log in to unmask]]
> On Behalf Of Thomas Baker
> Sent: Wednesday, March 14, 2012 10:05 PM
>
> On Wed, Mar 14, 2012 at 08:02:27PM -0400, Jeff Young wrote:
> > I suspect that HTML5 with embedded semantics will end up as the de
> facto form
> > of higher level abstraction.
>
> Hi Jeff,
>
> I'm not sure I understand... Are you suggesting that HTML5 will
become
> usable
> as the preferred "abstract" form of representing patterns (instead of,
> say,
> SPARQL, as in Dan's example, or N-Triples), or are you making a deeper
> point...? Are you thinking that HTML5 will become so ubiquitous and
> well-known
> that users will likely be able to read it?
Hopefully I'm splitting some hairs that are worth splitting.
Factor out the "query language" (i.e. SPARQL/SQL/CQL/OpenSearch/etc.).
The "abstract form" that is left is "information". How that information
gets sliced on a distributed network isn't that important anymore
because any missing bits are presumably an HTTP GET away (i.e. "Linked
Data" discretely or in bulk). It's just a caching/network efficiency
issue at that point. Likewise, it doesn't ultimately matter whether the
information is serialized as (RDF/)XML, N-Triples, XHTML+RDFa,
HTML5+Microdata, and any other imaginable digital form because the
transformations between them are increasingly trivial.
Jeff
>
> Tom
>
> > Tom Baker <[log in to unmask]> wrote:
> >
> > On Wed, Mar 14, 2012 at 05:00:59PM -0400, Tom Baker wrote:
> > > eg. 1: AP Use Case - "combining DC, FOAF + SKOS for
> > > locating colleague subject interests"
> > ...
> > > SELECT ?ilabel ?iblurb ?wphp ?name
> > >
> > > WHERE
> > > {
> > > [ rdf:type foaf:Agent;
> > > foaf:name ?name;
> > > foaf:workplaceHomepage ?wphp;
> > > foaf:homepage [ dc:subject [ skos:label ?ilabel;
> skos:scopeNote ] ]
> > > ]
> > > }
> >
> > The example above shows a pattern for using four vocabularies to
> describe
> > something for a particular purpose ("locating colleague subject
> interests").
> >
> > I'd like to suggest a "lower-level" pattern for consideration.
> Consider the
> > following (non-exhaustive) possible variants:
> >
> > 1. String value only (using the DC-RDF convention of rdf:value):
> >
> > :X dcterms:subject :Y
> > :Y rdf:value "Textile design--China--
> History"
> >
> > 2. String value with Vocabulary Encoding Scheme:
> >
> > :X dcterms:subject :Y
> > :Y rdf:value "Textile design--China--
> History"
> > :Y dcam:memberOf
> <http://purl.org/dc/terms/LCSH>
> >
> > 3. String value with SKOS Concept Scheme:
> >
> > :X dcterms:subject :Y
> > :Y skos:prefLabel "Textile design--China--
> History"
> > :Y skos:inScheme
> <http://purl.org/dc/terms/LCSH>
> >
> > 4. Value URI, alone:
> >
> > :X dcterms:subject
> <http://id.loc.gov/authorities/subjects/sh85134312>
> >
> > 5. Value URI with (possibly redundant?) context:
> >
> > :X dcterms:subject
> <http://id.loc.gov/authorities/subjects/sh85134312>
> > <id:sh85134312> skos:inScheme
> <http://purl.org/dc/terms/LCSH>
> >
> > Is it clearly "best practice" to use one of these variants? Or are
> there
> > circumstances in which one might favor one over the other?
> >
> > Would it be useful to move these examples to a higher level of
> abstraction --
> > i.e., express these examples not only as RDF triples, but in XML
> Schema or
> > Schematron? If so, is it useful to have an abstract syntax that is
> one layer
> > removed from RDF -- e.g., that labels the bits of information shown
> above as
> > Property URI, Value URI, VocabularyEncodingScheme URI (or
> ConceptScheme URI)...
> > -- in short, an abstract syntax for DCAM?
> >
> > Note that this example highlights an aspect of the mapping of DCAM
to
> RDF --
> > its use of rdf:value -- which has, through the evolution of best
> practice, turned
> > into Not-Best Practice.
> >
> > If the potential value of DCAM lies in providing a frame for
examples
> of Best
> > Practice, is it more important to get the set of examples right or
to
> get the
> > more generalized abstract syntax right? In the case above, there is
> more than
> > one way to do it. Is it perhaps enough to assemble useful examples,
> starting
> > with simple patterns like those above, on up to higher-level
patterns
> like the
> > one Dan presents?
> >
> > Discuss...
> >
> > Tom
> >
> > --
> > Tom Baker <[log in to unmask]>
>
> --
> Tom Baker <[log in to unmask]>
|