Re: Show me the money - (was Subjects as Literals)
On 7/11/2010 4:25 AM, Dave Reynolds wrote: Jena, which Jeremy's software is based on, *does* allow literals as subjects internally (the Graph SPI) and the rule reasoners *do* work with generalized triples just as most such RDF reasoners do. However, we go to some lengths to stop the generalized triples escaping. So the lack of subjects as triples in the exchange syntax or the publicly standardized model has had no detrimental impact on our ability to work with them internally. I have noticed similar points - a lot of reasoner based software, and graph internals software, and probably triple storage software will allow subjects as literals - but when considering systems and applications that actually do something useful (rather than just the internals) then you interface with people, and the difference between a literal and something else is crucial. This is where I see the costs. Jeremy
Re: Subjects as Literals
On 7/5/2010 3:40 PM, Hugh Glaser wrote: A particular problem in this realm has been characterised as S-P-O v. O-R-O and I suspect that this reflects a Semantic Web/Linked Data cultural difference, SNIP You see this as a problem of having a literal in the subject position. I might equally decide it is a problem with having literal in the object position. Literals are literals wherever they appear - they have no deeper semantics, and they certainly do not identify anything other than the literal that they are, if that makes sense. SNIP Ah, perhaps the nub. The subject is no more the thing being talked about than the object. I am not asking for symmetry of the grammar, if I understand what you mean. I am asking for the freedom to express the statements I want in the way I want, so that I can query the way I want. At the risk of repeating myself: If someone wants to say 666 foo:isTheNumberOf bar:theBeast and I have to tell them (as I do) ah, you can't say that, you need to introduce a resource numbers:666 rdfs:label 666. ... or bar:theBeast foo:hasNumber 666 I actually feel pretty stupid, having told them that RDF represents relations in a natural and basic way. In fact, I always feel a bit embarrassed when I get to the bit in my slides that shows there are two sorts of triples, as I have just said that the triples are just a directed graph. Just to mischievously throw a further linguistic spanner in the works (maybe that's a troll alert) http://en.wikipedia.org/wiki/Ergative%E2%80%93absolutive_language If we consider RDF as an ergative language, then the first position is necessarily an agent, and moreover, literals MUST NOT be agents http://www.w3.org/2001/01/mp23 (My first research paper was on the Basque auxiliary verb, see Carroll and Abaitua 1990) This would have interesting consequences for n-ary predicates Jeremy
Re: Show me the money - (was Subjects as Literals)
On 7/1/2010 8:44 PM, Pat Hayes wrote: Jeremy, your argument is perfectly sound from your company's POV, but not from a broader perspective. Of course, any change will incur costs by those who have based their assumptions upon no change happening I was asking for the economic benefit of the change, as opposed to the elegance benefit. Personally, I am wholly convinced by the elegance argument - but it will not convince my management, nor should it. I suspect there are several other companies and other open source activities that have investments that assume literals do not occur in subject position. Elegance is not, IMO, a sufficient argument to negate those investments. (The sort of thing we are talking about, is what sort of display is appropriate for a subject of a triple - we know that it is not a literal, so certain code paths, and options are not considered). Of course, in an industrial consortium costs to one member maybe justified by benefits to another - but costs to any member do need to be offset by some benefit to some member ... I have yet to see much of an argument (Henry got a small bit of the way), that there are any such benefits (i.e. ones which have a dollar, euro or yuan value). I have pointed to dollar costs ... I expect to see some such benefit. I don't think that expectation is unreasonable, more a boundary that keeps people honest ... and not just indulging in an intellectual game (he says politely). Jeremy
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On 7/2/2010 12:00 PM, Dan Brickley wrote: Or maybe we should all just take a weekend break, mull things over for a couple of days, and start fresh on monday? That's my plan anyhow... Yeah, maybe some of us could meet up in some sunny place and sit in an office, maybe at Stanford - just like last weekend! Jeremy
Show me the money - (was Subjects as Literals)
I am still not hearing any argument to justify the costs of literals as subjects I have loads and loads of code, both open source and commercial that assumes throughout that a node in a subject position is not a literal, and a node in a predicate position is a URI node. Of course, the correct thing to do is to allow all three node types in all three positions. (Well four if we take the graph name as well!) But if we make a change, all of my code base will need to be checked for this issue. This costs my company maybe $100K (very roughly) No one has even showed me $1K of advantage for this change. It is a no brainer not to do the fix even if it is technically correct Jeremy
Re: Show me the money - (was Subjects as Literals)
On 7/1/2010 10:18 AM, Yves Raimond wrote: Or, an even simpler use-case: storing metaphones for strings in a triple store. OK - and why are these use cases not reasonably easily addressable using the N-ary predicate design pattern with a two place ltieral predicate i.e. instead of Lit1 p1 nonLit use nonLit p1 Lit1 instead of Lit1 p lit2 use _ p1 Lit1 _ p2 Lit2 === Not quite the same, but it will work - and save me a large amount of really very boring work Jeremy
Re: Show me the money - (was Subjects as Literals)
On 1 Jul 2010, at 17:38, Jeremy Carroll wrote: I have loads and loads of code, both open source and commercial that assumes throughout that a node in a subject position is not a literal, and a node in a predicate position is a URI node. On 7/1/2010 8:46 AM, Henry Story wrote: but is that really correct? Because bnodes can be names for literals, and so you really do have literals in subject positions No? It is really correct that I have loads and loads of such code. This code conforms with the RDF Concepts and Abstract Syntax Recommendation 2004 Jeremy
Re: Show me the money - (was Subjects as Literals)
On 7/1/2010 11:51 AM, Henry Story wrote: So just as a matter of interest, imagine a new syntax came along that allowed literals in subject position, could you not write a serialiser for it that turned 123 length 3 . Into _:b owl:sameAs 123; length 3. ? I couldn't because chunks of my code are low level utils that are expected to, for example, write out what they read in, so I can't make transforms in the middle. Jeremy
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
David Booth wrote: I agree, but at the W3C RDF Next Steps workshop over the weekend, I was surprised to find that there was substantial sentiment *against* having literals as subjects. A straw poll showed that of those at the workshop, this is how people felt about having an RDF working group charter include literals as subjects: http://www.w3.org/2010/06/28-rdfn-minutes.html Charter MUST include: 0 Charter SHOULD include:1 Charter MAY include: 6 Charter MUST NOT include: 12 I was one of the MUST NOTs to my surprise. Here are the reasons I voted this way: - it will mess up RDF/XML - RDF/XML is horrid but we had consensus that it was unfixable - i.e. we need to live with it. - however little work the WG does is too much in terms of the real obstacles to SW success (following Dan from http://lists.w3.org/Archives/Public/semantic-web/2010Mar/0196.html [[ What I feel is missing (despite the *millions*) that has been thrown at the Semantic Web brand, is the boring slog of getting the base tools and software polished. ]] ). In particular my view is that literals as subjects is not part of the problem to be solved. - this is a purists' desire not a practical obstacle. No value-adding argument made for a change of this magnitude. It's a bug. Fixing it may cost $0.5M to $1M say, maybe more. I don't see that much return. Jeremy
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Jiří Procházka wrote: I wonder, when using owl:sameAs or related, to name literals to be able to say other useful thing about them in normal triples (datatype, language, etc) does it break OWL DL yes it does (or any other formalism which is base of some ontology extending RDF semantics)? Not OWL full Or would it if rdf:sameAs was introduced? It would still break OWL DL Best, Jiri OWL DL is orthogonal to this issue. The OWL DLers already prohibit certain RDF - specifically the workaround for not having literal as subjects. So they are neutral. I reiterate that I agree whole-heartedly with the technical arguments for making this change; however the economic case is missing. Jeremy
Re: The status of Semantic Web community- perspective from Scopus and Web Of Science (WOS)
Dan Brickley wrote: However it did not leave any footprint in the academic literature. We might ask why. Like much of the work around W3C and tech industry standards, the artifacts it left behind don't often show up in the citation databases. A white paper here, a Web-based specification there, ... it's influence cannot easily be measured through academic citation patterns, despite the fact that without it, the vast majority of papers mentioned in http://info.slis.indiana.edu/~dingying/Publication/JIS-1098-v4.pdf would never have existed. IIRC there was an explicit proposal by an earlier European paper (I think with Fensel as an author) to align some academic work with the W3C effort, essentially to provide branding, name recognition and a transfer path for the academic work Maybe: OIL: Ontology Infrastructure to Enable the Semantic Web Dieter Fensel 1, Ian Horrocks 2, Frank van Harmelen 1, Deborah McGuinness 3, and Peter F. Patel-Schneider 4 Given the current dominance and importance of the WWW, a syntax of an ontology exchange language must be formulated using existing web standards for information representation. Ying Ding's paper suffers from excluding technical papers such as W3C recs. These are widely cited, typically moreso than academic work. They also have better review process than academic stuff. I tend to agree with Dan that her work misrepresents what really happened. Jeremy
Re: Ontology modules and namespaces
Hi Simon I have only just seen your question about namespaces and saw that the discussion so far has missed discussing the relevant namespace standards (even the somewhat silly dispute about whether TopBraid Composer follows the standards concerning namespaces and XML Base: for the record, it does). Basically there are three: XML Namespaces [1], RDF Schema, and RDF/XML Syntax. OWL, for example, defers to all three of these. There is a foundational issue in that XML Namespaces were done in a bit of a hurry, and then the way that RDF interacts with them isn't the same as when they are being used in XML. So first: from the point of view of the logical meaning of an RDF or OWL document, namespaces are completely irrelevant. The role of namespaces is to organize names into (informal) collections, for the convenience of the user (in this case the ontologist). Hence, if you find it more convenient to use one namespace instead of several then you should. There is quite a gap between the Namespaces in XML Rec. and RDF. The former says simply: [[ Definition: An *XML namespace* is identified by an IRI reference [RFC3987] http://www.w3.org/TR/2006/REC-xml-names11-20060816/#IRIRef; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]] so that a namespace is a collection of names. RDF/XML [2] gives a mechanism for mapping namespace qualified names to RDF URI References (intended to be compatible with IRI Refs), and hence to URIRef nodes in an RDF graph. RDF Schema [3] (the RDF Vocabulary Description Language) then gives informal definitions to the various names in both the rdf and rdfs namespaces. A key half paragraph giving insight into the relationship between namespaces and vocabularies is found in: [[ The core vocabulary is defined in a namespace informally called 'rdfs' here. That namespace is identified by the URI-Reference http://www.w3.org/2000/01/rdf-schema# and is associated with the prefix 'rdfs'. This specification also uses the prefix 'rdf' to refer to the RDF namespace http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-Namespace http://www.w3.org/1999/02/22-rdf-syntax-ns#. ]] The relationship between vocabularies (and ontologies) and namespaces is informal. Often the terms in a vocabulary or ontology are defined in one or two namespaces. There is no prohibition on using a vocabulary in which every term is from its own namespace. The use of namespaces allows us to use prefixes, which allows us to avoid writing cumbersome URIs too many times. Jeremy Carroll TopQuadrant [1] http://www.w3.org/TR/2006/REC-xml-names11-20060816/ [2] http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ [3] http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ On Oct 26, 2009, at 10:25 AM, Simon Reinhardt wrote: Hi, It is becoming somewhat popular for large ontologies to be split into a core ontology file and module ontology files (which import the core). Normally each module then gets its own namespace for the terms defined in it. I was wondering though if that is too complicated for users of the ontologies. I have seen confusion of sioc and sioct (the prefixes for the SIOC core and the SIOC Types module namespaces) and when such vocabularies get higher adoption by people not so well versed with ontologies I can see it happen a lot more often. So as an alternative I want to explore the idea of just using one namespace shared between the core and the modules. The advantage would be not having to guess which namespace to use. One disadvantage for the developer(s) of the ontology is that a local name can only be used in one of the modules or core, you can't use the same word under a different namespace with a different meaning. Another disadvantage is that if you want the terms to dereference to the ontology files they have been defined in then you can only do that with a / namespace (and you have to set up lots of redirects). My questions: What do you think of that idea? Can you see any other advantages or disadvantages? Do you think several namespaces are not confusing at all? And what are the main advantages to splitting up ontologies into modules other than being easier to organise? Do they justify a higher burden on the ontology users? Thanks, Simon
