SPM Notes
Software Project Management Syllabus
UNIT-1
UNIT-2
UNIT 3
UNIT 4
Are updated soon.......UNIT-2
UNIT 3
UNIT 4
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Person>
<foaf:name>Peter Parker</foaf:name>
<foaf:mbox rdf:resource="mailto:peter.parker@dailybugle.com"/>
</foaf:Person>
</rdf:RDF>
In other words, there is a person, with the name "Peter Parker
",
who has an email address of "peter.parker@dailybugle.com
".
foaf:mbox_sha1sum
whose value is a SHA1
encoded email address complete with the mailto:
URI scheme prefix. The FOAF
project wiki has a handy reference page pointing to a number of different ways of generating a SHA1 sum.
<foaf:Person>
<foaf:name>Peter Parker</foaf:name>
<foaf:gender>Male</foaf:gender>
<foaf:title>Mr</foaf:title>
<foaf:givenname>Peter</foaf:givenname>
<foaf:family_name>Parker</foaf:family_name>
<foaf:mbox_sha1sum>cf2f4bd069302febd8d7c26d803f63fa7f20bd82</foaf:mbox_sha1sum>
<foaf:homepage rdf:resource="http://www.peterparker.com"/>
<foaf:weblog rdf:resource="http://www.peterparker.com/blog/"/>
</foaf:Person>
Which is a slightly richer description of Peter Parker, including some granularity
in the
markup of his name through the use of foaf:title
, foaf:givenname
,
and foaf:family_name
. We also now know that Peter Parker is male
(foaf:gender
) and has both a homepage (foaf:homepage
) and a
weblog (foaf:weblog
).
rdf:about
attribute
on the foaf:Person
resource:
<foaf:Person rdf:about="..uri to identify peter..."/>
That's because there is still some debate around both the social and technical
implications of assigning URIs to people. Which URI identifies you? Who assigns these
URIs?
What problems are associated with having multiple URIs (assigned by different people)
for
the same person? Side-stepping this potential minefield, FOAF borrows the concept
of an
"inverse
functional property" (IFP) from OWL, the Web Ontology Language. An inverse functional
property is simply a property whose value uniquely identifies a resource.
foaf:mbox
, foaf:mbox_sha1sum
, and foaf:homepage
;
consult the schema documentation for the complete list. An application harvesting
FOAF data
can, on encountering two resources that have the same values for an inverse functional
property, safely merge the description of each and the relations of which they are
part.
This process, often referred to as "smushing", must be carried out when aggregating FOAF data to ensure that data
about different resources is correctly merged.
<foaf:Person>
<foaf:name>Peter Parker</foaf:name>
<foaf:mbox_sha1sum>cf2f4bd069302febd8d7c26d803f63fa7f20bd82</foaf:mbox_sha1sum>
</foaf:Person>
<foaf:Person>
<foaf:name>Spiderman</foaf:name>
<foaf:mbox_sha1sum>cf2f4bd069302febd8d7c26d803f63fa7f20bd82</foaf:mbox_sha1sum>
</foaf:Person>
Applying our knowledge that foaf:mbox:sha1sum
is an inverse functional
property, we can merge the descriptions together to discover that these statements
actually
describe a single person. Spiderman is unmasked! While perfectly valid, it may not
be
desirable in all circumstances, and flags the importance of FOAF aggregators recording
the
source (provenance) of their data. This allows incorrect and potentially malicious
data to
be identified and isolated.
foaf:mbox_sha1sum
and foaf:mbox
) as uniquely identifying a
person, this is not the same thing as saying that all email addresses are owned by
a unique
person. What the FOAF schema claims is that any email address used in a
foaf:mbox
(or encoded as a foaf:mbox_sha1sum
) property uniquely
identifies a person. If it doesn't, then it's not a suitable value for that property.
foaf:knows
property is used
to assert that there is some relationship between two people. Precisely what this
relationship is, and whether it's reciprocal (i.e. if you know me, do I automatically
know
you?), is deliberately left undefined.
foaf:knows
is simple: one foaf:Person
foaf:knows
another. The following example shows two alternative ways of writing
this using the RDF/XML syntax. The first uses a cross-reference to a person defined
in the
same document (using rdf:nodeID
), while the second describes the
foaf:Person
"in situ" within the foaf:knows
property. The
end result is the same: Peter Parker knows both Aunt May and Harry Osborn.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<foaf:Person rdf:nodeID="harry">
<foaf:name>Harry Osborn</foaf:name>
<rdfs:seeAlso rdf:resource="http://www.osborn.com/harry.rdf"/>
</foaf:Person>
<foaf:Person>
<foaf:name>Peter Parker</foaf:name>
<foaf:knows rdf:nodeID="harry"/>
<foaf:knows>
<foaf:Person>
<foaf:name>Aunt May</foaf:name>
</foaf:Person>
</foaf:knows>
</foaf:Person>
</rdf:RDF>
The other thing to notice is that, in addition to the foaf:knows
relationship
between Peter and Harry, a link has also been introduced to Harry's own FOAF document,
using
the rdfs:seeAlso
property. Defined by the RDF Schema specification, the
rdfs:seeAlso
property indicates a resource that may contain additional
information about its associated resource. In this case it's being used to point to
Harry
Osborn's own FOAF description.
rdfs:seeAlso
property that FOAF can be used to
build a web of machine-processable metadata; rdfs:seeAlso
is to RDF what the
anchor element is to HTML. Applications can be written to spider (or "scutter" using the FOAF community's
terminology) these RDF hyperlinks to build a database of FOAF data.
foaf:knows
won't fit all applications, particularly
those geared to capture information about complex social and business networks. However,
this doesn't mean that FOAF is unsuitable for such purposes; indeed FOAF has the potential
to be an open interchange format used by many different social networking applications.
foaf:knows
. Stepping outside of FOAF for a
moment, we can briefly demonstrate one example of this using the relationship schema
created by Eric Vitiello.
foaf:knows
including parentOf
, siblingOf
, friendOf
, etc. The
following example uses these properties to make some clearer statements about the
relationships between Peter Parker and some of his contemporaries:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:rel="http://www.perceive.net/schemas/relationship/">
<foaf:Person rdf:ID="spiderman">
<foaf:name>Spiderman</foaf:name>
<rel:enemyOf rdf:resource="#green-goblin"/>
</foaf:Person>
<foaf:Person rdf:ID="green-goblin">
<foaf:name>Green Goblin</foaf:name>
<rel:enemyOf rdf:resource="#spiderman"/>
</foaf:Person>
<foaf:Person rdf:ID="peter">
<foaf:name>Peter Parker</foaf:name>
<rel:friendOf rdf:resource="#harry"/>
</foaf:Person>
<foaf:Person rdf:ID="harry">
<foaf:name>Harry Osborn</foaf:name>
<rel:friendOf rdf:resource="#peter"/>
<rel:childOf rdf:resource="#norman"/>
</foaf:Person>
<foaf:Person rdf:ID="norman">
<foaf:name>Norman Osborn</foaf:name>
<rel:parentOf rdf:resource="#harry"/>
</foaf:Person>
</rdf:RDF>
While it is possible to model quite fine-grained relationships using this method,
the most
interesting applications will be those that can infer relationships between people
based on
other metadata. For example, have they collaborated on the same project, worked for
the same
company, or been pictured together in the same image? Which brings us to the other
commonly
used FOAF class, Image.
foaf:depiction
property we can make a statement
that says "this person (Resource) is shown in this image". FOAF also supports an inverse
of
this property (foaf:depicts
) that allows us to make statements of the form:
"this image is a picture of this Resource". The following example illustrates both
of these
properties.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<foaf:Person rdf:ID="peter">
<foaf:name>Peter Parker</foaf:name>
<foaf:depicts rdf:resource="http://www.peterparker.com/peter.jpg"/>
</foaf:Person>
<foaf:Person rdf:ID="spiderman">
<foaf:name>Spiderman</foaf:name>
</foaf:Person>
<foaf:Person rdf:ID="green-goblin">
<foaf:name>Green Goblin</foaf:name>
</foaf:Person>
<!-- codepiction -->
<foaf:Image rdf:about="http://www.peterparker.com/photos/spiderman/statue.jpg">
<dc:title>Battle on the Statue Of Liberty</dc:title>
<foaf:depicts rdf:resource="#spiderman"/>
<foaf:depicts rdf:resource="#green-goblin"/>
<foaf:maker rdf:resource="#peter"/>
</foaf:Image>
</rdf:RDF>
This RDF instances says that the image at
http://www.peterparker.com/peter.jpg
is a picture of Peter Parker. It also
defines a foaf:Image
resource, i.e. an image which can be found at a specific
URI, that depicts both Spiderman and the Green Goblin. Elements from the Dublin Core namespace are often added to FOAF
documents to title images, documents, etc.
foaf:maker
property which is used to relate a resource to its creator. The
dc:creator
term isn't used here due to some issues with its loose
definition.
rdfs:seeAlso
link will make the data discoverable
foaf:knows
relationships.
Here's the foafnaut view starting
from my description