Re: Concrete mixers

Hi Dan
I agree much with your observation that 'good' models are prerequisite 
to solving these problems long-term.
I've looked closely on schema.org, concluding that its use cases are a 
bit too contextual for my taste.
Thus in my schema, I do try to sidestep some of the 'wooliness' you mention.
Overall, its predicators implement a "verb:connector" construct. A 
"connector" indicates whether a triple's object is in a nominative, 
genitive, dative, accusative, indicative or other relation with respect 
to its subject. Samples of these constructs:
a. Author: Moby Dick -- is:this -- Person: Herman Melville
b. Author: Moby Dick -- is:that -- Author: Omoo
c. Author: Herman Melville -- is:of -- Book: Moby Dick
d. Person: Herman Melville -- is:of -- City: New York
e. Book: Moby Dick -- is:for -- Group: General Audiences
f. Person: Herman Melville -- is:a -- Nationality: American

A 'predicate namespace' reflects past, present, future, conditional, 
existential &or other tenses of relations; a triple's nouns are 
therefore strictly quarantined to the context of the subject or object 
of the triple.
a. Ticket: X12345 -- is:for -- Person: ABCD
b. Ticket: X12345 -- was:for -- Person: ABCD
c. Ticket: X12345 -- will-be:for -- Person: ABCD
d. Ticket: X12345 -- is:for -- Organization: ABCD
e. Ticket: X12345 -- had:by -- Organization: ABCD
f. Ticket: X12345 -- had:by -- Person: ABCD
g. Person: ABCD -- has:this -- Ticket: X12345

OK now to address the question of a triple's object that in some 
contexts is a text-string, and others a resource, I note the obvious: 
text-strings are resources as well "within" which one finds multiple 
translations (as a for instance, but also it's the container for 
lots&lots of metadata too!)
a. Book: Moby Dick -- has:this -- Title: Moby Dick
b. Title: Moby Dick -- is:a -- Type: Title (i.e., Title: Moby Dick -- 
rdf:type -- Class: Title)
c. Title: Moby Dick -- is:of -- Book: Moby Dick
d. Title: Moby Dick -- iso:en -- "Moby Dick"
e. Title: Moby Dick -- iso:ar -- "موبي ديك"

So bottom line I am trying to say that, while understandable I suppose 
from a desire for a rough equivalence of Assembler data structures with 
semantic models, those which allow nouns into the context of predicators 
yield a concrete number of  inefficiencies, in practice.  Rather, true 
semantic models in my view encapsulate constructs found in human 
language; anything less is an "engineering shortcut" causing -- with no 
doubt -- massive pulsing migraines for us all as competitive use cases 
emerge contradicting already published and authoritative "stable" 
models, during a process such as you note.

Meaning properties like "rdf:type" "rdfs:subClassOf" and "rdfs:label" 
are intimately flawed; nounal expressions have no business but as a 
subject or object.  And most of the properties at schema.org, designed 
from the same flawed perspective, are equally problematic.

Anyway I hope to publish aspects of this work soon - thanks for listening
regards/john

On 1/5/2015 1:14 AM, Dan Brickley wrote:
> [snip]
>
> Just a quick comment: one reason for schema.org's seeming woolly-ness
> regarding type/property associations is that the entire (1200+ term)
> structure is being gradually evolved as new use cases and vocabulary
> proposals are developed. Rather than e.g. on monday saying "author has
> range Person" and then on tuesday refining that to say "well actually
> we meant to say author has range Agent which has subtypes Person,
> Organization", the approach is more like saying "author
> kinda-goes-with Person", where kinda-goes-with (aka
> http://schema.org/rangeIncludes) doesn't let you conclude much.
> Otherwise parties who believed you on monday when you said that
> authors are always people will be disappointed and confused to find a
> tuesday-based description in which something is said to be written by
> an Organization. You might reasonably respond that it would be better
> to get the basic modeling right in the first place rather than make it
> up as you go along, and in practice much of the schema now isn't
> changing much so it could feasibly be documented more tidily and
> marked as unlikely-to-change. But that was the basic thinking: things
> were changing a lot, and we didn't want to bloat out the documentation
> of an already large structure with additional 'modeling artifact'
> types that were not expected to be used in actual instance data...
>
> Dan

Received on Monday, 5 January 2015 20:44:36 UTC