若有心的大大可以幫忙翻譯的話 請不能直接要翻譯軟體或google翻 翻譯問題(科技英文)，很多，請各位大大幫忙 - 趣味新聞網

發表日期 2007-12-10T21:11:04+08:00

     若有心的大大可以幫忙翻譯的話，請不能直接要翻譯軟體或google翻，
因為這是科技英文，很多關鍵字跟文法都不同
請各位大大幫忙，我翻的一個頭兩個大瞭
還請幫忙翻譯的大大多費心，感恩~~
The Semantic Web uses the Resource Description
Framework3 as the representation
model. Statements in RDF are triples, consisting
of a subject, a predicate, and an object. A
triple asserts that a subject has a property with
some value. For example, the triple Cedric
rdf:type foaf:Person states that Cédric is
a person. RDF Schema4 is the schema language
for the Semantic Web. It lets you describe
vocabularies in terms of classes and
properties. For example, the triple foaf:name
rdfs:domain foaf:Person states that name
is a property of a person. For readability, the
combination of RDF and RDF Schema is often
referred to as RDF(S).
Decentralized data
Although the Semantic Web is data oriented
and the World Wide Web is document oriented,
both are fundamentally decentralized, heterogeneous,
and open. The Semantic Web isn’t a
global database, centralized in one location with
one agreed-upon schema and one meaning. Instead,
anyone can make any statement at any location,
using any vocabulary or structure. In
contrast, as table 1 shows, traditional databasedriven
Web applications are centralized, with a
fixed schema, vocabulary, and data source.
Conceptual and physical decentralization
leads to
■ naming differences, because one person
might describe a book’s “author,” a second
the book’s “writer,” and a third its
“creator”;
■ differences in data structures, because some
users might describe their language skills in
their personal profiles while others describe
their pets or their favorite colors; and
■ federated storage, because statements can
be published to any Web location without
central registration.
The Semantic Web has no central data repository,
no central agreement on meaning, and no
central policy on terminology or structure.
Incompatible models
Developing Semantic Web applications requires
handling the RDF(S) data model in a
programming language. Although most software
development follows the object-oriented
paradigm, programming in RDF is triplebased.
An object-oriented API for Semantic
Web data would map RDF Schema classes to
programming classes, RDF resources to programming
objects, and RDF predicates to
methods on those objects. Such an API lifts
data elements into first-class citizens in the
language (for example, http://xmlns.com/
foaf/0.1/firstName => Person.first-
Name), thus making it easier to handle them.
The semantics of classes and instances in
RDF Schema assume an open-world model
and are based on description logic. Static object-
oriented type systems, on the other hand,
typically assume a closed-world model and so
are constraint-based. As table 2 demonstrates,
this fundamental semantic difference affects
Web application frameworks that, based on
the relational model, automatically map database
tuples to programming objects.
Dynamic general-purpose languages (such
as Smalltalk, Perl, Python, and Ruby) are dynamically
typed, typically have higher-order
constructs (for example, passing methods to methods),
and support complete reflection—
both introspection (obtaining information on
objects at runtime) and intercession (modifying
objects at runtime). Such dynamically
typed languages address the mismatches in
table 2 as follows:
■ Class membership. These languages’ dynamic
typing doesn’t require that we define
object classes statically, but lets us determine
them at runtime by the object’s
capabilities. Dynamic typing maps well to
RDF(S) class membership, which can also
change dynamically during runtime. Although
objects in most dynamically typed
languages can have no more than one
class at a time, we can change that behavior
at runtime (using intercession).
■ Inheritance. Similarly, most dynamically
typed languages don’t support multiple
inheritance. However, you can add this
behavior through reflection because, in
the absence of behavioral definitions, inheritance
in RDF(S) only affects object
typing.
■ Object conformance. Dynamically typed
languages typically don’t require objects
to strictly conform to their class definitions,
but instead let them deviate from
their classes by, for example, specifying a
different behavior (method implementation)
for several objects of the same class.
■ Semistructured data. These languages’
flexibility often removes the need for attribute
definitions in classes and lets instance
attributes have various values of
various types without problems.
■ Runtime evolution. Because dynamically
typed languages are interpreted and don’t
rely on strictly predefined classes, they’re
well suited for flexible environments in
which both data and schema can evolve.
Their introspection features let programs
interrogate the schemas and domain vocabulary
at runtime.
Dynamic languages’ flexible capabilities
imply that type safety isn’t guaranteed and
that runtime errors can occur. However, we
tolerate these drawbacks to accommodate our
decentralized integration scenario.

[ 本帖最後由 兩極171 於 2007-12-10 15:56 編輯 ]

分享鏈接