- From: Jiří Procházka <ojirio@gmail.com>
- Date: Wed, 1 Jul 2020 02:45:48 +0200
- To: semantic-web@w3.org
- Message-ID: <29e90ad9-57ab-4b4c-449d-d96c30363c73@gmail.com>
I don't consider that as radical of a proposal as many do. People value different RDF(S)/OWL/RIF/N3 features differently, as their use cases differ. I think a lot of real RDF usage in the wild doesn't care much about any RDF logic, inference, entailments and treat RDF as an upgraded data language, most value provided by IRI/URI identifiers, shared vocabularies and graph structure. They are authoring their data, ingesting, cleaning and filtering external data, merging it and processing in based on their own algorithms/logics. This group would be mostly fine with some "RDFCore" without blank nodes and maybe other stuff. Just graphs and triples. On the other hand people who care about logic and entailments usually care about it a lot and what RDF(S) provides is not a lot. If you want more, it gets really complex. I agree that even the RDF specifications are not approachable for a common programmer. On the other hand what seems approachable and simple is N3, and it can even do more than RDFS! RDFS constructs can be defined using N3 rules, blank nodes can be replaced by explicit N3 existential variables over entire graph. As any rule language seems simple to me than OWL/RDFS, RIF could be an alternative to N3. I can read rules fine, they can be accompanied by helping descriptions, but with OWL/RDFS we have just the descriptions and formal semantics which (both) have been misunderstood by many. So how about specifying a simple clean RDFCore and rule based logic on top of that? How is that for a radical proposal? J. PS: For the RDF -> RDFCore cleanup there have been numerous ideas, but off top of my head what has resonated with me is: 1) No blank nodes. 2) Include named graphs/surfaces, vocabulary for relations between them and triples, to overshadow RDF reification. 3) Vocabulary for semantic extensions, if their terms break any features, like monotonicity. 4) Subject and object should allow the same node types, property possibly too. 5) Remove and have a recommended descriptive vocabulary (no special semantics) for highly reusable stuff like: collections, containers, 6) Recommendation and vocabulary for representing n-ary relations. 7) Good support for binary data literals. 8) Simple resource equality rules (IRI/URI rules are complex). 9) Vocabulary for dereferencing / Linked Data. rdf:seeAlso. 10) Consider merging literals into resources for example using something like ValueProperty (subclass of rdf:Property, range: literals). Data URI scheme? Replace literal language tags and literal datatypes by a descriptive vocabulary. On 7/1/20 12:32 AM, David Booth wrote: > On 6/30/20 3:12 PM, Patrick J Hayes wrote: >>> On Jun 30, 2020, at 9:40 AM, David Booth wrote: >>> I REALLY wish that some PhD students would take on this >>> challenge: to design a higher-level successor to RDF, >>> with a top-line goal of making it easy enough for AVERAGE >>> developers (middle 33% of skill), who are new to it, to be >>> consistently success. >> >> Might that be (a subset of?) OWL2 using the Manchester syntax? > > I doubt it, even though the Manchester syntax does make OWL much more > understandable than OWL-in-Turtle. Two reasons: > > - I think OWL itself is too hard for average developers (mid 33%). > Although the various OWL constructs in isolation -- expressed in > Manchester syntax, at least -- are understandable enough, average > developers (the onese I've seen) don't exhibit the precise careful > reasoning of a logician. And they don't approach applications as a > logician would, by starting with a few iron-clad axioms and rules that > they've thought long and hard about, adding data, and then turning a big > reasoner crank to get the desired results. They approach applications > more operationally, through a series of small steps that they can > successively implement and test, to eventually produce the desired > result at the end. > > - The majority of RDF (or graph database) applications that I see are > much more like big data integration problems than semantic inference > problems, and they typically do not need OWL. > > There certainly are some projects that make important beneficial use of > OWL -- based on the OBO Foundry ontologies, for example -- but from what > I've seen, they're not generally done by *average* developers. There's > usually a PhD or two involved. > > Anyway, that's what I've seen. Others might have different views. > > David Booth >
Received on Wednesday, 1 July 2020 00:46:34 UTC