It’s also worth noting that linked data is an API (a set of best practices for publishing data on the Web), whereas RDF doesn’t assume the Web. They aren’t the same thing.
For example, you can load RDF into Apache Spark/GraphX (useful structures) and then hammer it offline with useful operations on an cluster.
http://spark.apache.org/graphx/
http://spark.apache.org/mllib/
Jeff
On 8/18/16, 10:59 AM, "Bibliographic Framework Transition Initiative Forum on behalf of Murray, Ronald" <[log in to unmask] on behalf of [log in to unmask]> wrote:
>You stated the RDF graph structure assumption correctly - graph
>structures, implemented as networks - can be used to model...
>
>What RDF does *not* do is to supply or reference essential/useful graph
>structures or operations on graphs that could give meaning to and enable
>our bibliographic description network implementations. Your closest graph
>theory textbook will define many of those for us. The Wolfram Language
>show us how graph structures and operations can be implemented to operate
>on the network structures we model in RDF:
>
> http://reference.wolfram.com/language/guide/GraphsAndNetworks.html
>
>http://reference.wolfram.com/language/guide/GraphConstructionAndRepresentat
>ion.html
> http://reference.wolfram.com/language/guide/GraphVisualization.html
>
>http://reference.wolfram.com/language/guide/GraphPropertiesAndMeasurements.
>html
> http://reference.wolfram.com/language/guide/ComputationOnGraphs.html
> http://reference.wolfram.com/language/guide/SocialNetworks.html
>
>For a good example of what an operation on a RDF network-from-graph
>structure could provide, see the "Application" section of this
>FindClique() function:
>
> http://reference.wolfram.com/language/ref/FindClique.html
>
>If we fed a function like this RDF networks defined according to differing
>relationships that define a whole, we would naturally get differing
>cliques of the larger whole. Subparts of this particular function have
>been implemented within the library community - but it is important to be
>able to glimpse what the math underlying a RDF network structure can
>enable.
>
>Ron Murray
>
>
>
>On 8/17/16, 8:09 PM, "Bibliographic Framework Transition Initiative Forum
>on behalf of Young,Jeff (OR)" <[log in to unmask] on behalf of
>[log in to unmask]> wrote:
>
>>I don't think that linked data assumes you can cut text up into tiny
>>fragments that can be trivially pasted back together. It assumes that
>>reality can be modeled and published as a graph in such a way that makes
>>information easier to find and reuse in other contexts. RDF isn't a
>>miracle and it's wrong to expect that.
>>
>>On Aug 17, 2016, at 4:27 PM, Stuart Yeates <[log in to unmask]>
>>wrote:
>>
>>>> What does RDF have to do with bi-directional text?
>>>
>>> Actually quite a bit. RDF, (like MARC) takes a reductionist approach to
>>>text, assuming that you can cut text up into tiny fragments and then
>>>rebuild the content by trivially pasting them back together. BIDI showed
>>>some of fallacies in this approach. Unicode 8 (which includes
>>>signwriting) is going to re-enforce these, particularly in jurisdictions
>>>such as mine which give official recognition to sign languages.
>>>
>>> cheers
>>> stuart
>>> --
>>> I have a new phone number: 04 463 5692
>>> https://www.facebook.com/VUWLibrary / https://www.facebook.com/TKMPC
>>>
>>> ________________________________________
>>> From: Bibliographic Framework Transition Initiative Forum
>>><[log in to unmask]> on behalf of Martynas Jusevičius
>>><[log in to unmask]>
>>> Sent: Thursday, 18 August 2016 12:42:02 a.m.
>>> To: [log in to unmask]
>>> Subject: Re: [BIBFRAME] Life after MARC?
>>>
>>> What does RDF have to do with bi-directional text? RDF is a directed
>>> graph datamodel, text is only one of its node types (literals).
>>> Whatever you put in the literals, RDF doesn't care, nor should it.
>>>
>>> "rdf:PlainLiteral: A Datatype for RDF Plain Literals (Second Edition)"
>>> spec actually says:
>>>
>>> "As with plain literals, this datatype can associate language tags
>>> with Unicode strings, but it does not provide its own facilities for
>>> representing natural language utterances. Unicode bidirectional
>>> control characters [BIDI] may be used within these literals, like all
>>> other Unicode characters."
>>>
>>> Plain literals have been superseded by xsd:string in RDF 1.1 though,
>>> so this is probably outdated. I guess need to check XML Schema
>>> Datatypes for BIDI support.
>>>
>>> There is also a relevant W3C doc here:
>>> https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
>>>
>>> On Wed, Aug 17, 2016 at 2:20 PM, Lammert, Richard
>>> <[log in to unmask]> wrote:
>>>> On Tue, Aug 16, 2016 at 10:17 PM, Andrew Cunningham
>>>> <[log in to unmask]> wrote:
>>>>>
>>>>> RDF is showing its age and has a number of inherent weaknesses,
>>>>> particularly bidi support. Parsing BIBFRAME to generate HTML
>>>>>fragments when
>>>>> more that one embedding level is involved is non-trivial.
>>>>>
>>>>> A.
>>>>
>>>> Andrew, thank you for this reality check. Almost fifty years ago, when
>>>>MARC
>>>> was being developed, it could handle any bibliographic description
>>>>that was
>>>> needed--as long as it used the Latin alphabet (plus a few diacritics).
>>>> Twenty years ago, MARC specifications were changed to permit the entire
>>>> Unicode character set. This year, the world's major bibliographic
>>>>utility
>>>> has upgraded to allow that entire character set.
>>>>
>>>> While all W3C specifications are inherently Unicode-based, your remark
>>>>about
>>>> bidi support is well taken. I would hate to move to a new standard that
>>>> could handle any bibliographic description that was needed--as long as
>>>>it
>>>> was written left to right. Then we would only have to wait for good
>>>> right-to-left support to take care of *all* our bibliographic needs.
>>>>
>>>> Richard
>>>>
>>>> --
>>>>
>>>> Rev. Richard A. Lammert e-mail: [log in to unmask]
>>>> Technical Services Librarian mail: 6600 N. Clinton St.
>>>> Systems Librarian Fort Wayne, IN 46825-4916
>>>> Kroemer Library phone: 260-452-3148
>>>> Concordia Theological Seminary
|