David,
Of course we have to model the Message as a class of objects, together with verbs that connect it to sender and contract and time and so forth. Yes, one can
model all the separate possible message contents, but the reasoning problem is to compare the assertions made in diverse messages with diverse content.
The IFTMIN message whose subject is Neptune’s Pride and whose location is New York can be interpreted to:
...#MessageXXX #asserts (the named graph containing): ...#NeptunesPride #isLocatedIn ...#NewYork
Or it can be interpreted to:
...#MessageXXX #asserts ...#LocationYYY,
...#LocationYYY #locatedThing ...#NeptunesPride
...#LocationYYY #locationOfThing ...#NewYork
(The latter is the common approach used in natural language modeling – reifying all the verbs.)
These two different approaches give rise to different reasoning strategies, and different complexities in the reasoning problem. You never need named graphs
if you reify predicates into states. But that always adds at least one level of indirect to all of the reasoning processes.
What we can do with named graphs is to create subproblems for simpler reasoning. (There were also other motivations for use of the captured assertions.)
So, it was just a strategy choice.
-Ed
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of David Price
Sent: Friday, June 13, 2014 12:15 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes
Hi Ed,
Curious ... rather than trying to use named graphs to represent Messages, did you even consider modelling Messages and its content in your ontology? In your scenario, that seems a reasonable thing to do ... or maybe that's the 15926 in
me talking, although that idea is in PLCS too.
We're working on our third EPIM semantic data hub project called LogisticsHub and it sounds like we have very similar requirements, except ELH is tracking cargo containers and the locations are RFID readers.. We've not needed to use named
graphs to manage the message validation though, so that's why I'm curious.
We've found in this and previous projects is that RDF/OWL named graphs are usually better used as the "bucket of triples" for more practical/bookkeeping tasks like access control, caching, managing automated update of background facts,
deleting data when a new version of the same report data needs to be uploaded to fix errors, versioning schemas, etc. There are, of course, times when things are just too complex (e.g. like very complex access control rule requirements) to be handled using
named graphs. In those cases, you just have to model your way out of trouble ... at least that's what we've found.
Our particular application involved validating the contents of messages received from suppliers. So what we need to capture is not just “Shipment XX1234 is
in New York”, but rather “Message MM78910 says that Shipment XX1234 is in New York”. And we have to compare that with other knowledge we have, and other reports we may have from other sources. If there is no conflict in all that information, we can accept
the statement as true, but when there is a conflict, some remedial action must be taken, lest the operations information base become inconsistent. The particular USE of the named graph for “Shipment XX1234 is in New York” is as an operand of the RDF verb/predicate
...#asserts (which is just a clarification of ‘says’). So that particular use/role of the Named Graph is an “assertion”. That is, it is the intent of the message that the named graph be accepted as a fact.
You are right when you say that a named graph could be considered a ‘topic’ – a sentence that plays a role in verbs relating to conversation, of which assertion
is a special case. In a related way, a named graph may be used as an operand of RDF verbs/predicates that express “modalities”: S is possible/impossible; S is required; S is desirable/undesirable; S is prohibited.
Others have discussed the use of the Named Graph as an operand of ...#causes, in which there are two roles for named graphs, loosely called “cause” and “effect”.
In that usage both named graphs might be taken as facts a priori, and the intent of the use is to relate them “causally”. There are many other uses of named graphs for other purposes. From a natural language point of view, I would say that a named graph
is used whenever a sentence is the subject or object of the verb in another sentence. In formal logic, a named graph is a particular representation of a ‘nominalized proposition’, literally a “proposition converted to a noun” (because ‘nouns’ and pro-nouns
are the speech elements that play roles in verbs and thus in sentences, or equivalently, in other ‘propositions’).
BTW, you are also correct about named graphs being used as buckets of triples. Used in that way, a named graph is a “knowledge management object” – a “set
of knowledge” (only maybe a “theory”) that is manipulated as a body. And in particular, that is a way in which metadata can be attached to parts of a knowledge base. For example, this set of triples together represents a state of the world at a given time.
National Institute of Standards & Technology
Systems Integration Division
100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
From: Frank
Guerino [mailto:Frank.Guerino@xxxxxxxxx]
Sent: Thursday, June 12, 2014 7:56 PM
To: [ontolog-forum]
Cc: Barkmeyer, Edward J
Subject: Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes
Can I ask you (or anyone who might know the answer) to clarify why they're called "Assertions"?
I can certainly see them as being…
- a topic
- an index
- or even just "a bucket of triples"
However, based on the English definition of the word "assertion," I don't think I understand their labeling as Assertions.
--
Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)
http://www.if4it.com
1.908.294.5191 (M)
We also manage assertions. This is one of the reasons why the RDF folk invented RDF Named Graphs -- a bucket of triples with an identifier.
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
|
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|