MDaconta@aol.com wrote:
> Hi Frank,
>
> Thanks for the response. I will try and express the point better...
Sure thing. Thanks for the comments.
>
> In a message dated 11/13/2002 5:38:14 AM US Mountain Standard Time,
> fmanola@mitre.org writes:
>
> I'm not sure I fully understand your point. At the moment, as you say,
> the structure of the example is:
>
> <Staff Member> <address> <blank node>
> <blank node> <street> "1501 Grant Avenue"
>
> whereas you're suggesting it should be
>
> <Staff Member> <livesAt> <Address>
> <Address> <street> "1501 Grant Avenue"
>
> However, it seems to me that all you've done is changed the name of the
> predicate. The changed name for the predicate may, to some people,
> convey the semantics in English more accurately (it could also have
> been
> "hasAddress"), but the semantics seem to me to be exactly the same:
> the
> blank node represents an address, which has various properties itself
> (street, and so on). In other words, it seems to me that the example
> could just as easily have been written, using your predicate name:
>
>
>
> The point I disagree with above is when you say, "the blank node
> represents an address" because no where do we connect it with
> the concept (or Class) "Address". As you say below,
> this could be resolved if we specify a type and then that clears up the
> semantic confusion. I would guess that a blank node then really just
> means "thing" (unless we type it).
This depends on what "means" means. If I create a resource, or a blank
node, I get to decide what it means, and anyone who understands my
vocabulary or the structure I'm using (through some means or other)
might share that meaning (e.g., they might understand that the thing at
the end of my "address" property was an address). As far as
machine-interpretable meaning is concerned, though, *any* resource,
blank node or not, just means "thing" unless you provide some additional
information about it (like a type, which of course the machine has to
understand too). That is, it isn't just blank nodes that have to be
typed to have this meaning: resources with URIs do too. URIs don't
carry meaning with them (or at least, they aren't supposed to be
interpreted as carrying meaning in RDF).
>
> <Staff Member> <livesAt> <blank node>
> <blank node> <street> "1501 Grant Avenue"
>
> with the exact same semantics.
>
> The only difference between this and what you've suggested seems to be
> that in your example, the object of the first statement is <Address>,
> which I presume means it has a URI (and possibly that it has a type
> such
> as "Address"). But the point of the example was an assumption that you
> for some reason *didn't* want to assign the address a URI (you could
> have given the blank node a type if you wanted). In other words,
> use of
> a blank node here isn't as much a semantic issue as it is a matter of
> URI management. If you want to assign everything a URI, that's cool,
> but I don't think it changes the structure of the model. Perhaps I'm
> not understanding your point?
>
>
>
> My point was that an un-typed blank node is semantically ambiguous.
> I think the solution is to type the blank node. I still am not 100%
> clear on
> the best practices for modeling statements about instances versus
> statements
> about classes of things. I may need to work on some more examples ... if
> you know any good references that talk about this distinction please let
> me know.
You generally make statements about classes of things in schemas. So
the place to say that the property <address> has a range of class
<Address> would be in a schema. In the original example, though, I
wanted to represent the specific address of a specific staff member.
That means that the thing on the end of Joe's <address> (or <livesAt>)
property needs to be something that represents an individual address,
not the class of addresses. So I need to use either a blank node, or a
resource with a URI. Either way, adding a type property would convey
more information about that instance (to someone or something who
understood what class <Address> meant).
>
> Just to close the loop, then to assign the type to the blank node I
> would use rdf:type with the resource being a previously defined
> <rdfs:Class rdf:about="#Address"> right?
>
Right.
--Frank
--
Frank Manola The MITRE Corporation
202 Burlington Road, MS A345 Bedford, MA 01730-1420
mailto:fmanola@mitre.org voice: 781-271-8147 FAX: 781-271-875